Bricscad pulls in ardour-2
in Linux
Is it just me or is bricscad actually dependent on Ardour (version 2) in Linux?
Why am I being made to install an application I don't want -- or at least a version that is gradually going out of support?
It seems odd for a CAD application to be pulling in a full DAW application as a dependency.
Why am I being made to install an application I don't want -- or at least a version that is gradually going out of support?
It seems odd for a CAD application to be pulling in a full DAW application as a dependency.
0
Comments
-
Hi Onyeibo,
In my experience, BricsCAD has never tried to pull in Ardour. I agree that it would be very odd for a CAD application to depend on a digital audio application.
I'm guessing it is something unique about your system.0 -
Which distribution are you using? I tried BricsCAD on Fedora and OpenSUSE and none of the installers pulled Ardour.
Tom0 -
Which distribution are you using? I tried BricsCAD on Fedora and OpenSUSE and none of the installers pulled Ardour.
Tom
I use Fedora. I've been experiencing this from Fedora 18 through 20. Now I have migrated to Rawhide (F22) and, guess what, it happened again. It pulls in Ardour-2 (and not even the more attractive Ardour-3). I suppose there is a file or library in Ardour-2 that it needs (dnf provides */whatever resolves it and makes it available). I'm not sure how the depsolving points to Ardour but it does. Take a look at this:
[code]dnf remove bricscad*
Dependencies resolved.
===================================================================================================================================================================================================================
Package Arch Version Repository Size
===================================================================================================================================================================================================================
Removing:
ardour x86_64 2.8.16-11.fc22 @System 14 M
aubio x86_64 0.3.2-16.fc22 @System 223 k
bricscadv14 x86_64 14.2.14-1 @System 434 M
cwiid x86_64 0.6.00-25.20100505gitfadf11e.fc22 @System 72 k
ladspa x86_64 1.13-13.fc22 @System 116 k
lash x86_64 0.5.4-21.fc22 @System 486 k
libart_lgpl x86_64 2.3.21-12.fc22 @System 130 k
libgnomecanvas x86_64 2.30.3-9.fc22 @System 964 k
libgnomecanvasmm26 x86_64 2.26.0-11.fc22 @System 335 k
liblo x86_64 0.27-5.fc22 @System 161 k
liblrdf x86_64 0.5.0-8.fc22 @System 53 k
libpng12 x86_64 1.2.50-8.fc22 @System 442 k
lilv x86_64 0.20.0-2.fc22 @System 153 k
serd x86_64 0.20.0-1.fc22 @System 130 k
sord x86_64 0.12.2-1.fc22 @System 68 k
sratom x86_64 0.4.6-2.fc22 @System 38 k
suil x86_64 0.8.2-2.fc22 @System 77 k
Transaction Summary
===================================================================================================================================================================================================================
Remove 17 Packages
Installed size: 451 M
[/code]
Perhaps to replicate this you may need to download the bricscad package locally and install via bash (nah, that's a weak one). Perhaps its because its a 64-bit system. I don't know. Its weird.0 -
Just like I suspected
It just occurred to me to check the deplist for bricscadv14 rpm. Here is the bash session:
[CODE]yum deplist bricscadv14
Loaded plugins: langpacks
package: bricscadv14.x86_64 14.2.14-1
dependency: /bin/sh
provider: bash.x86_64 4.3.24-1.fc22
dependency: libGLU.so.1()(64bit)
provider: mesa-libGLU.x86_64 9.0.0-7.fc22
dependency: libICE.so.6()(64bit)
provider: libICE.x86_64 1.0.9-2.fc22
dependency: libSM.so.6()(64bit)
provider: libSM.x86_64 1.2.2-2.fc22
dependency: libc.so.6()(64bit)
provider: glibc.x86_64 2.20.90-1.fc22
dependency: libclearlooks.so()(64bit)
provider: ardour.x86_64 2.8.16-11.fc22
dependency: libcups.so.2()(64bit)
provider: cups-libs.x86_64 1:1.7.5-7.fc22
dependency: libcurl.so.4()(64bit)
provider: libcurl.x86_64 7.38.0-1.fc22
dependency: libexpat.so.1()(64bit)
provider: expat.x86_64 2.1.0-10.fc22
dependency: libfontconfig.so.1()(64bit)
provider: fontconfig.x86_64 2.11.1-5.fc22
dependency: libgthread-2.0.so.0()(64bit)
provider: glib2.x86_64 2.41.5-1.fc22
dependency: libgtk-x11-2.0.so.0()(64bit)
provider: gtk2.x86_64 2.24.24-3.fc22
dependency: libpng12.so.0()(64bit)
provider: libpng12.x86_64 1.2.50-8.fc22
dependency: libpth.so.20()(64bit)
provider: pth.x86_64 2.0.7-25.fc22
dependency: libstdc++.so.6()(64bit)
provider: libstdc++.x86_64 4.9.1-9.fc22
dependency: libuuid.so.1()(64bit)
provider: libuuid.x86_64 2.25.1-1.fc22
[/CODE]
Bricscad is looking for libclearlooks.so()(64bit) ... and ardour provides that. That's strange. Looking for other providers0 -
That's strange. I have two Fedora 20 systems, both of them with 64bit BricsCAD installs and none of them has Ardour installed.
Tom0 -
Clearlooks is a GTK theme or engine. This one:
http://gnome-look.org/content/show.php?content=19527
In Debian it is provided by the package gtk2-engines. I'm not sure what the equivalent is on Fedora.
Look for a package called gtk-engines or gtk2-engines. Perhaps the correct package is uninstallable on your system, and that's why the package manager is going the long way around and installing Ardour. It's confused about the best place to get the Clearlooks theme.0 -
Okay, now gtk-engines package is available on rawhide repositories. The behaviour persists but there is a new observation. When I run 'dnf install bricscadv14' without prior installation of gtk-engines, the package manager pulls in Ardour2 with other dependencies (ignoring gtk-engines). Whereas, when I install gtk-engines first then attempt a bricscad installation, it works as expected and Ardour is left out.
Strange.
I think there might be a packaging issue somewhere, perhaps in the scripts within the bricscad package. In any case, it appears the bricscad package is not totally conforming to fedora packaging standards.0
This discussion has been closed.