On Tue, May 08, 2001 at 02:34:52PM -0300, Henrique de Moraes Holschuh wrote: > > FWIW, I do all my development under testing. I virtually ignore unstable > > unless I need a specific package from it. > AFAIK, I cannot do that. If I build against testing, I help the breakage by > adding yet another package that depends on the outdated libraries that are > in testing, therefore helping those libraries to be held instead of > upgraded. It's a positive feedback loop. Unless I misunderstand testing, > obviously, and such loop does not exist. You're probably overestimating the possibility of loops. In almost all cases, they just don't occur. If it doesn't matter whether you're using the version from testing or unstable of the package, then you're fine. For example, say you've got a package foo. foo 1.0-1 depends on libc6 (>= 2.2.1-1) and is in testing, along with libc6 2.2.2-4, say. Meanwhile, libc6 2.2.3-1 is in unstable, and it's still waiting two days before its time is up. There's no loop there (no matter how you build foo 1.0-2) because the package in testing will happily work with either the old libc6 or the new libc6. The worst case in the above is if you build with unstable, in which case foo 1.0-2 may have to wait a couple of days longer than you might like while libc6 gets recompiled or some RC bugs get fixed. And that's not a particularly bad worst case, in general. In general, you (as a package maintainer) are supposed to be able to ignore testing, and do what you like (although you might receive bug reports now and then telling you to start building against new libraries, like libncurses5 instead of 4, say). > If it happens to be very important package (none of mine are, AFAIK), I'll > compile it in a testing chroot, upload it with urgency high or critical, and > downgrade all RC bugs. Gag. Don't do this. testing can't do it's job if you lie outright to it. If there's a problem mail -devel. You shouldn't have outstanding RC bugs anyway. Seriously. > Maybe I misunderstand the testing mechanics, and libs will be always > upgraded when their dependencies allow it, thus flushing a lot of packages > from testing. They will: the problem only occurs when things break both forwards and backwards compatibility (ie, new packages don't work on the old libraries _and_ old packages don't work with the new libraries). This is rarely the case. 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. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net)
Attachment:
pgph6hN1W8HYC.pgp
Description: PGP signature