Dependency hell redux

cbbrowne@ntlug.org cbbrowne@ntlug.org
Fri, 15 Jun 2001 23:18:01 -0500 (CDT)


Bjorn Helgaas wrote:
> Rob> What about a downloadable .tar.gz file which is all n Megs of
> Rob> libraries and gnucash and whatnot, and the user is told to "cd ~ &&
> Rob> tar -zxvf <filename>".  That would create a ~/gnucash-app directory...
> 
> Using a .tar.gz file makes it easier for developers/packagers, but harder 
> for users.  Most people are users.  Wearing my "user" hat, I want my 
> package management experience to be seamless.  Every package should 
> install, configure, and upgrade the same way.

What is "preferred" is to have whatever is the most convenient format to
install on a given distribution.

On Debian, that would be as a suitable set of .deb packages with
dependancies.

On RHAT, that would be as a set of .rpms with RHAT dependancies.

On SuSE, that would be as a set of .rpms with SuSE dependancies.

On *BSD, that would be as a Ports package [which is vaguely equivalent
to a Debian source package].

On Slackware, that would be as a Slackware-oriented "tarball."

Those five options provide some useful guidance in indicating the
total set of "options of value," and I'd argue that it's important
to look at all of them and NOT to just assume "we'll build RPMs and
be done with it."

The problem with saying "let's just worry about RPMs" is that saying
"RPM" isn't specific enough; the RPMs have to be constructed with a set
of library dependancies tailored to the distribution because there is
_not_ a standard for "how RPMed libs are named."  [If RHAT ever
decided to truly try to conform to LSB, and worked with Mandrake/SuSE
to agree on interoperable libs, it might be a different story.  Probably
not gonna happen in _this_ world...]

The problem with tarballs is that they're typically _not_ convenient
to users, as few distributions use them.  [Possibly only Slackware.
I'm fairly surprised that Slackware didn't head to using BSD Ports
as the packaging mechanism, by the way...]  Furthermore, if the
tarballs are going to include the whole wad of GNOME libs, then we
head towards the situation of either:
  a) Having to have libs installed in some GnuCash-specific place,
     so that there might be several copies of the _same_ GNOME libs if
     one had GnuCash as well as RHAT as well as Ximian Gnome installed,
     or
  b) If attempt is made to drop the "GnuCash-tarballed-Gnome libs"
     into normal spots in /usr/lib, then this is highly likely to
     conflict with the native packaging.

Both options provide a nice big "blech!"

Long and short is that there _will_ need to be independent efforts
to do the "systems integration" to make GnuCash colloquially installable
on all these sorts of systems.

What is desparately needed on the RPM side of things is to have tools
equivalent to Debian's "dpkg builder suite" that actually try to manage
the overall distribution, rather than the present situation where RPM
basically builds a "tarball" for each package, with relatively little
cooperation at the _source package_ level...

Not gonna happen tomorrow...
-- 
Christopher Browne
<http://www.ntlug.org/~cbbrowne/resume.html>
cbbrowne@acm.org
(613) 225-3689