The Grumpy Editor's guide to (some) development distributions [LWN.net]

The Grumpy Editor's guide to (some) development distributions

Posted Nov 8, 2007 8:51 UTC (Thu) by bakterie (subscriber, #37541)
Parent article: The Grumpy Editor's guide to (some) development distributions

I disagree with the classification of Gentoo as a development 
distribution. Being source-based does not automatically make it a 
development distribution. You can choose if you want to use unstable 
packages or not. By default you will not be using unstable packages.

(Log in to post comments)

The Grumpy Editor's guide to (some) development distributions

Posted Nov 8, 2007 11:17 UTC (Thu) by evgeny (subscriber, #774) [Link]

> I disagree with the classification of Gentoo as a development distribution. [...] By default
you will not be using unstable packages

Using only stable packages in Gentoo is not the same as using, say, a "stable" version of
Debian. A "stable" OS in most people's mind is when you install a distro, configure it, and
can forget about the OS itself except doing regular updates (security and otherwise important
bugs). It is not the same in Gentoo. Today you installed, configured it, everything works
fine. Tomorrow you do "emerge world" and - oops - libexpat now version 2.0.something instead
of yesterday's 1.95.something. Both are stable. But the library sonames are different, so now
you have to revdep-rebuild all the related packages (which are dozens, both system- and
desktop-level), and until the process successfully finishes (if it does), your box is
literally unusable. And that's before we talk about your own soft which depends on expat (and
need to be recompiled manually) or, worse yet, third-party binary packages where simply there
is no hope.

I used to run Debian testing and unstable, and Gentoo is something like these in respect to
stability and maintenance headaches; YMMV, of course. However, Gentoo provides an
unprecedented level of package customization (both in terms of version number and build-time
options), and that's why I like it - it's been on my work desktop and 2 servers for more than
3 years. It was also on my previous laptop, but for the new one I decided on Ubuntu, since for
the relatively small amount of time I use it heavily (mostly for trips abroad), the
maintenance time is disproportionally large.

The Grumpy Editor's guide to (some) development distributions

Posted Nov 8, 2007 12:48 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link]

Particularly when employing the Paludis package manager. http://paludis.pioto.org

The Grumpy Editor's guide to (some) development distributions

Posted Nov 8, 2007 15:22 UTC (Thu) by iabervon (subscriber, #722) [Link]

The expat update (and the similarly timed curl update) were, in my opinion, completely
botched. The way it's supposed to work is that both versions of expat would be installed at
the same time (since they don't have any overlapping files, since the soname of the library
changed, which is the fundamental solution for dependancy problems), and the older one could
be discarded once you'd rebuilt all the packages that had been built against the old library.
Unfortunately, the package maintainer decided to discard the older library at once (since the
system isn't set up to discard it automatically when it is safe to do so), which made
everything that uses it break in the transition (and revdep-rebuild isn't quite clever enough
at package ordering to necessarily fix the broken packages you need to use to build other
broken packages first, although it tries).

So there is a mechanism in place to avoid this problem, and it's used for a lot of packages,
but was not used in this case, which is why there were problems.

The Grumpy Editor's guide to (some) development distributions

Posted Nov 8, 2007 16:18 UTC (Thu) by evgeny (subscriber, #774) [Link]

> So there is a mechanism in place to avoid this problem

You're absolutely right, there was a way to handle this specific case gracefully. Still, such
a situation (soname change) is impossible in the first place in most "stable" distributions. I
could use another example, e.g., once a udev update added a non-standard user to one of
/etc/udev/rules.d/*, with a result that my ldap-pam based system hung for several minutes
during the boot; etc. In short, when versions of _all_ packages change from time to time, a
chance for a, let's say, surprise is obviously higher ;-) One should certainly have this in
mind when opting for Gentoo.

The Grumpy Editor's guide to (some) development distributions

Posted Nov 8, 2007 17:03 UTC (Thu) by iabervon (subscriber, #722) [Link]

An soname change may be impossible in a particular release of a stable distribution, but there
have been rather a lot of soname changes in "Debian stable" over the years. Of course, this
only happens at a new release, but that tends to make release times especially tricky. This is
particularly true because stable distribution upgrades are a rare enough event that the
procedures are never sufficiently carefully tested to be a suitable operation to perform on a
stable system.

The Gentoo mechanism for the stable version is pretty much unique in that you can run a system
forever without ever doing anything that's either beyond end-of-life or is outside of the
normal update process, whereas other systems require an upgrade, outside of the normal
process, eventually. Of course, the actual Gentoo "stable" distribution doesn't necessarily
avoid causing occasional breakage, but that's an implementation issue rather than a design
issue.

The Grumpy Editor's guide to (some) development distributions

Posted Nov 23, 2007 6:22 UTC (Fri) by leio (subscriber, #41189) [Link]

It's not that we wanted to give you a world of pain. It was that we wanted to avoid lots of
pain that is involved in this specific case when two DIFFERENT ABI version of libexpat are on
a system. Library A depends on expat and library B depends on library A and expat - Library A
gets rebuilt and will use libexpat.so.1 version, while library B still uses libexpat.so.0.
User launches an application linking to Library B, both expat versions are mapped in and
providing symbols, things get mixed up between them, enter a world of chaos and random hard to
explain crashes caused by the specific case this library works and is used, which made
preserve_old_lib method usage not a good option as that leads to exactly that chaos crashy
world.

We do not have a mechanism in place to avoid that. Manually it was possible to workaround it
by making a libexpat.so.0 pointing at libexpat.so.1, because then the same library is used by
both library A and B, but in this instance this workaround it worked just for most cases due
to the ABI breakage being small.

And yes, I am one (out of about three or four) persons responsible for the decision on which
route we went with the expat upgrade and I stay by it.

The Grumpy Editor's guide to (some) development distributions

Posted Nov 9, 2007 0:42 UTC (Fri) by zlynx (subscriber, #2285) [Link]

> Today you installed, configured it, everything works fine. Tomorrow you do "emerge world"
and - oops - libexpat now version 2.0.something instead of yesterday's 1.95.something. Both
are stable. But the library sonames are different, so now you have to revdep-rebuild all the
related packages (which are dozens, both system- and desktop-level), and until the process
successfully finishes (if it does), your box is literally unusable.

There are some tricks you can do with CONFIG_PROTECT to force portage to save old versions of
library files.

The Grumpy Editor's guide to (some) development distributions

Posted Nov 12, 2007 16:21 UTC (Mon) by evgeny (subscriber, #774) [Link]

> There are some tricks you can do with CONFIG_PROTECT to force portage to save old versions
of library files.

CONFIG_PROTECT is about protecting _config_ files...

The Grumpy Editor's guide to (some) development distributions

Posted Nov 12, 2007 17:30 UTC (Mon) by zlynx (subscriber, #2285) [Link]

> CONFIG_PROTECT is about protecting _config_ files...
That does not mean you can not (ab)use it for protecting library files.

Or without the double negative...
CONFIG_PROTECT does work to protect non-config files.