Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

Dependencies

Posted Dec 5, 2002 9:16 UTC (Thu) by ekj (subscriber, #1524)
In reply to: Dependencies by aglet
Parent article: Coming soon: gnucash 1.8

It *is* a problem. Case in point. I had Mandrake 8.1 and wanted to run the newest gnucash, this was when my distro was maybe 5 months old or so.

urpmi gnucash*

Complained that it needed to upgrade ~25 libraries, about 5 of which urpmi knew of no source for. No problem I said, go ahead. But then it turned out that this would break many of my older applications, so they would *also* need to be upgraded. In principle it should be possible to have two different versions of the same lib, in practice this works sometimes, and othertimes not.

So, to run this one program I would have been forced to:

Locate the 5 missing libraries (i.e on rpmfind.net)
Update the 25 libraries.
Update the ca 100 programs that depended on a particular version of one of these libraries.

All to run this one program. Oh yeah, and I forgot to mention, this only works if *all* of the things from the steps above are compiled with the same compiler. You see C++ is not nessecarily binary-compatible even if compiled from the same sources, it also needs to be compiled with the same compiler. (or atleast a similar one.)

This is not a reasonable amount of effort to put into installing a single program. What it means in practice is that I, and probably very many others, have completely given up on trying out new betas and CVS-versions and suchlike of Gnucash, and instead stick with the version that comes in our distro and "just works". This is a pity, because it reduces the amount of testing a new version gets before it becomes the official one.

(Log in to post comments)

Dependencies

Posted Dec 5, 2002 9:59 UTC (Thu) by aglet (guest, #1334) [Link]

Ah, but beta testing is different to just wanting to run the application (which is what I nuderstood the previous poster to be saying). Perhaps you should keep a small "bleeding edge" partition if you can't manage to keep your stable stuff working as well as running recent betas? Maybe a switch in distribution would help -- I drag in a few packages from the Debian unstable & testing distributions into my stable laptop, it seems to work fine...

It might be useful for the GNUcash people to provide giant statically-linked binaries specifically to enable easy beta testing -- this might well increase the exposure & therefore coverage of testing, as you imply.

Dependencies

Posted Dec 5, 2002 12:04 UTC (Thu) by ranger (guest, #6415) [Link]

Debain isn't the only distro out there of course. There's no need to switch distros, upgrading to Mandrake 9.0 should be sufficient, at most the user could add a cooker source to urpmi to install the required libraries (and remove it afterwards, to prevent getting a whole bunch of other possibly semi-broken software).

But, installing the deps on a pre-Gnome2 distro to be able to run a development version of GTK/Gnome software is probably not feasible, at least not without requiring upgrades on much of the software (since many of the dependencies are complex, to allow gnome1.x software to co-exist with Gnome2 may require upgrading Gnome1.x libraries, requiring software depending on those libraries to be upgraded also).

Why doesn't one see this with KDE though, I wonder ...

Dependencies

Posted Dec 11, 2002 23:22 UTC (Wed) by Wilddev (guest, #8514) [Link]

I'm not quite sure what you're implying here, but GnuCash 1.8.0 is a GNOME 1.4 application and doesn't require any GNOME2 libraries. Also as someone actively involved in GNOME I know that GNOME 1.4 and GNOME2 happily co-exist allowing you to run applications developed for either platform as required.

Dependencies

Posted Dec 11, 2002 23:18 UTC (Wed) by Wilddev (guest, #8514) [Link]

I'd like to point out that mdk 8.1 _comes_ with GnuCash 1.6.2. The only dependency problems you should encounter with the new version of GnuCash over the one supplied as part of mdk 8.1 is an upgraded g-wrap library. There is no 25 library upgrade problem. If, however, you are running KDE as your desktop, then of course as GnuCash has currently only a GNOME 1.4 based front end you will need to install enough of GNOME to run it. (a KDE developer has recently started working on a KDE based interface for the GnuCash engine incidentally).
There is quite a bit of misinformation about GnuCash's requirements out there. GnuCash is no more difficult to install with GNOME 1.4 already installed than any of the other GNOME Office applications (Gnumeric, Evolution, Abiword, etc).

Dependencies

Posted Dec 18, 2002 17:54 UTC (Wed) by dbreakey (guest, #1381) [Link]

This is not a library issue, but a packaging issue; unfortunately, I don't think that anyone has come up with a reasonable, usable solution for this. Consider the following:

Most libraries are backwards-compatible, at least to some degree. Developers of these libraries generally, as far as I can tell, try to ensure that libraries sharing the same major release number remain backwards-compatible.
Your distribution vendor is putting their reputation on the line by packaging everything together to provide a working system.
Your distribution vendor probably just doesn't have the time (most don't) to verify that earlier library versions still work with the latest and greatest version of any given application. Sadly, most vendors probably don't even have enough time to rely on the release notes to tell them this either.

Therefore, in order to continue producing a distribution that meets their desired level of quality (whatever that might be), most vendors only spend their time testing and validating the latest—or at least whatever point on the curve they want to be at; some vendors prefer to hang back a bit from the absolute latest sutff, while others like to live on the bleeding edge—releases of any given application.

The downside to this is that users, in order to upgrade to the latest version of one particular application, may be required to upgrade a large portion of their system in order to satisfy dependancies—dependancies which are determined by the vendor and hard-coded into the package information.

If you don't want to do this, you may want to start using one of the increasing number of "build from source" distributions, which will probably give you far more control over the exact content of your system.