Re: glibc: causes segfault in Xorg
On Wed, 04 May 2011, Russ Allbery wrote:
> Jon Dowland <jmtd@debian.org> writes:
> > On Wed, May 04, 2011 at 11:48:33AM +0200, Raphael Hertzog wrote:
>
> >> While I can sympathize with this (it's what I want as a developer),
> >> it's certainly not a good idea in Debian in general: we have many
> >> derivatives taking unstable/testing at various points in time, and we
> >> also want to make testing generally usable by end-users.
>
> I don't think mixing unstable and testing here as if they're the same
> thing is warranted. If we get common crashes, that's going to become an
> RC bug fairly quickly, and won't be propagated to testing.
Yeah, I would have liked to be able to respond: "OK for unstable, not OK for
testing". Unfortunately that's not the way it works.
We'll discover the problem in unstable fairly quickly but unfortunately
the bugs in the applications are already present in testing since the
change of behaviour of the library causes a regression in the application.
So ideally we should have in unstable the library with the new behaviour
and keep in testing the old behaviour until all the fixed applications
have made it to testing.
This is of course doable with "Breaks" once we know the affected
application (but that itself requires a lots of time) but it's a pain in
the case of something like libc6 that you want to see migrated soon enough
because it has the potential to make transitions very hard.
A way to implement this is to have a first upload with the change of
behaviour reverted, have it migrate quickly, do another upload and restore
the new behaviour and open an RC bug to keep this version out of testing.
Not very practical to say the least... (there's also the possibility to
have a t-p-u upload with the revert)
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
Reply to: