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

Preling but not gdm

Posted Jul 7, 2009 0:16 UTC (Tue) by khim (subscriber, #9252)
In reply to: Why people don't test development distributions by sjlyall
Parent article: Why people don't test development distributions

I know automation won't pick up everything but I would have thought the prelink and the gdm bugs mentioned would have been picked up by even simple "apply the update and reboot" testing.

Prelink will certainly be detected, but gdm... no luck: bug there killed your session when you tried to update, offline upgrade worked fine (it just killed the session of the unfortunate user who tried to use the system at the time).

The real solution is shown by Gentoo: package is added to the system in "masked" state. It's possible to use it - but you need to specifically ask for it. Once enough "success stories" are obtained the mask is removed and all "unstable" users are upgraded. Works good so far: I certainly never seen unstable Gentoo system which refused to even boot!

P.S. Number of success reports differes for type of package: for core packages (like baselayout, prelink, or glibc) it can be "few months of testing", but for fringe package like tofrodos it can be "one user other then the packager"...

(Log in to post comments)

Preling but not gdm

Posted Jul 7, 2009 14:49 UTC (Tue) by michaeljt (subscriber, #39183) [Link]

> The real solution is shown by Gentoo: package is added to the system in "masked" state. It's possible to use it - but you need to specifically ask for it.

You echo my thoughts. I'm sure many users would be happy (even eager) to test certain unstable packages that they are interested in. Compare that to the number who would be happy to work with an unstable distribution (I for one would be very reluctant to). The only thing that Gentoo is lacking in this respect is a way to pull in the dependencies of the unstable packages you wish to test without having to remove the stable versions that your other packages are using.

Preling but not gdm

Posted Jul 7, 2009 19:05 UTC (Tue) by cry_regarder (subscriber, #50545) [Link]

Fedora already has this. It is called bodhi. See:

http://bodhi.fedoraproject.org

But the discussion is about development __distributions__ not development __packages__.

Preling but not gdm

Posted Jul 9, 2009 19:40 UTC (Thu) by yokem_55 (subscriber, #10498) [Link]

Gentoo, while it is rare for a stable or even unstable update to completely hose a system, a couple of years ago they pushed through an upgrade to expat which bumped the .so version number, which in turn hosed everything depending on expat. On top of this, the usual tool for fixing missing libraries (revdep-rebuild) had some nasty weaknesses that made fixing one's system decidedly non-trivial. I personally had no idea what expat was or how much of a system depended on it (nearly everything that ran in X to start). There are still people running into this as the support thread for the issue in the Gentoo forums shows.

Preling but not gdm

Posted Jul 12, 2009 7:56 UTC (Sun) by dirtyepic (subscriber, #30178) [Link]

> The real solution is shown by Gentoo: package is added to the system in
> "masked" state. It's possible to use it - but you need to specifically
> ask for it. Once enough "success stories" are obtained the mask is
> removed and all "unstable" users are upgraded.

We do? ;) There are only a couple situations I can think of where a new package/version would be added to the tree in a masked state:

- you know it's going to break things and you need guin- er, testers to smoke out the worst of the bugs (eg. gcc-4.4)
- you have a large number of packages with interdependencies between each other that need to all be made available at the same time (eg. gnome)

...unless by masking you're actually referring to keywording (~arch / arch). Then yes, packages need to be in ~arch (unstable) a minimum of one month before they can be stabilized. We don't need success stories, just a lack of bug reports. Stabilization is done by dedicated arch-tester teams, so you will always have at least one other set of eyes on a package before it hits stable.

IMO Gentoo generally manages to keep the unstable tree in working order and usable enough for everyday work. I think this can be attributed in part to the fact that we don't do releases and therefore don't have that period of churn that conventional distros do where everything is getting updated at once. Basically, we don't have a development cycle; we're always in development.