[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Why are new package versions depending on libc6 in unstable?



On Thu, Nov 21, 2002 at 08:49:44AM -0500, Michael Stone wrote:
> Right. And the current system doesn't seem to be helping this. It looks
> at the moment that glibc isn't releasable, but we can't release until
> it's fixed. 

Apart from any potential security issues and the installer, we could
release testing now. It wouldn't be very spectacular, but we could do it.

> Wouldn't
> it be neat if the fate of certain core packages didn't tie up
> development for everything else? 

Possibly. Unfortunately it's not as simple as it sounds.

> If we didn't have this sort of
> dependency we wouldn't *have* to fix these bugs before we released
> sarge. (E.g., if libc was giving us trouble we'd defer that package to
> sarge+1.) 

That's fine. We did that with autoconf1.5 for woody, eg. The way to do
it is to say "ooops, we're stupid and can't cope with the mess we just
caused" and back it out -- this is hard to do with libc6 thanks to all
its dependents, but it's a simple matter of NMUing. Saying, oh, well,
nice try, but let's just forget that package until the next release
isn't something to encourage though.

And in any event, the bugs just aren't that difficult to fix.

> What we have now is *exactly* the situation you describe, in
> which all development is stalled and won't start until glibc is fixed

Development isn't stalled at all, you can keep doing whatever you like
and uploading it to unstable completely happily.

> (at which point everyone will say, "let's release now" and we'll
> suddenly discover and have to fix bugs in all the packages that finally
> make it into testing.)

No, we can say "let's release now" and people will discover that we
don't have an installer, and that we haven't managed to move sarge much
further along than woody was.

Look, I, and the buildd maintainers, understand your point, and heck,
I've argued for it myself before too. It *would* be nice if these testing
transitions were less dramatic. But the easiest way of doing this, and the
way with the least drawbacks, is just to maintain unstable competently,
and not use it as a dumping area for software we can't be bothered fixing.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

 ``If you don't do it now, you'll be one year older when you do.''

Attachment: pgp6rAW3ndR9C.pgp
Description: PGP signature


Reply to: