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