Re: Questions to testing/unstable

[Anthony Towns]

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 <[EMAIL PROTECTED]> 
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)


pgpAU8EVFwQko.pgp
Description: PGP signature

Re: Questions to testing/unstable

[Brian May]

> "Herbert" == Herbert Xu <[EMAIL PROTECTED]> writes:

Herbert> That means the library maintainer has stuffed up.  If
Herbert> he's done it properly, his libraries can go into testing
Herbert> wihtout having to wait for all its users to recompile.
Herbert> This used to be insignificant, but testing has made it
Herbert> much more important which IMHO is a very good thing.

This ideal is not practically possible with a complicated package like
heimdal-libs:

[520] [snoopy:unstable:bam] ~ >dpkg -L heimdal-lib
/.
/usr
/usr/lib
/usr/lib/libroken.so.9.2.1
/usr/lib/libcom_err.so.1.0.1
/usr/lib/libsl.so.0.1.1
/usr/lib/libss.so.0.1.3
/usr/lib/libasn1.so.2.2.0
/usr/lib/libkrb5.so.15.0.0
/usr/lib/libhdb.so.7.0.0
/usr/lib/libkadm5srv.so.7.0.3
/usr/lib/libkadm5clnt.so.4.2.1
/usr/lib/libgssapi.so.1.2.0
/usr/lib/libotp.so.0.1.2
/usr/lib/libroken.so.9
/usr/lib/libcom_err.so.1
/usr/lib/libsl.so.0
/usr/lib/libss.so.0
/usr/lib/libasn1.so.2
/usr/lib/libkrb5.so.15
/usr/lib/libhdb.so.7
/usr/lib/libkadm5srv.so.7
/usr/lib/libkadm5clnt.so.4
/usr/lib/libgssapi.so.1
/usr/lib/libotp.so.0
[...]

For instance, the next version of Heimdal, 0.3f could increase the
major version of libkrb5 from 15 to 16. This means all programs that
depend on the old heimdal-lib are now broken, because it is not
possible to install old and new at the same time (the other files
conflict).

So, just in case, I have the shlibs depends set so that all packages
must be recompiled for every upstream realize, just in case.

Of course, the proper solution would be to split heimdal-libs up, so
you have one library per package, but there are 11 libraries here!!!
I personally consider that to be too complicated.

Yes, another solution might be to combine some of the libraries
together (eg. make libasn1 a convenience library; combine e2fsprogs
and Heimdal's version of libcom_err, etc).  However, that is beyond
the scope of what I am prepared to do (in my limited time) as the
Debian maintainer. If anyone has plenty of spare time, please give
upstream any patches you may create to do this .

(lets assume for now that issues like libtool < 1.4 not recording
interlibrary dependencies properly have been fixed, as I will assume
that a) libtool 1.4 which has just been released solves this, and b)
that they have fixed 2 serious bugs which I found in the CVS version;
I still need to test it though).
-- 
Brian May <[EMAIL PROTECTED]>

Re: Questions to testing/unstable

[Herbert Xu]

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:

> On Tue, 08 May 2001, Herbert Xu 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.

That means the library maintainer has stuffed up.  If he's done it
properly, his libraries can go into testing wihtout having to wait for
all its users to recompile.  This used to be insignificant, but testing
has made it much more important which IMHO is a very good thing.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Questions to testing/unstable

[Henrique de Moraes Holschuh]

On Tue, 08 May 2001, Sam Hartman wrote:
> Henrique> AFAIK, I cannot do that.  If I build against testing, I
> Henrique> help the breakage by adding yet another package that
> Henrique> depends on the outdated libraries that are in testing,
> Or your could do shared library versions correctly so both versions
> can exist.  I realize it is hard, especially if your upstream is not

That's a problem for the library maintainers, currently none of my packages
are libraries. Correct versioning, as specified by the library package, is
already carried over to any packages built against it.

Anyway, avoiding to clobber an old lib in testing is not always possible, or
desirable. Sometimes, old stuff has to be removed due to security holes,
regardless of the fact that the ABI has changed. A serious proposal that
library maintainers start doing backports from unstable security fixes to
testing would die an horrible flaming death quite quickly IMHO.

I won't touch the topic about QA and yet another (unsupported -- it won't be
updated, because the ABI changed) layer of libraries.

If I do not want to get caught in an ABI change, and help a breakage in
testing, I have to build against unstable. It's that simple. If the ABIs of
the libs it depends on didn't change, the package will make it to testing.
If the ABIs changed, it won't (I am supposing the library package is doing
things right on the .so versioning, shlib definitions and package naming
area).

AFAIK, testing is supposed to be a half-baked frozen distro. Its existance
should be as transparent as possible for the developers, and help the
deployment of the next stable distro by shortening the freeze time.  It's
NOT an always-safe distro, nor is it meant to be. It is not a very secure
distro either because there are extra delays for a security fix to get to
testing.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


pgphmi0PYHcjG.pgp
Description: PGP signature

Re: Questions to testing/unstable

[Sam Hartman]

> "Henrique" == Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:

Henrique> AFAIK, I cannot do that.  If I build against testing, I
Henrique> help the breakage by adding yet another package that
Henrique> depends on the outdated libraries that are in testing,
Henrique> therefore helping those libraries to be held instead of
Henrique> upgraded.  It's a positive feedback loop. Unless I
Henrique> misunderstand testing, obviously, and such loop does not
Henrique> exist.

Or your could do shared library versions correctly so both versions
can exist.  I realize it is hard, especially if your upstream is not
committed to multiple major versions/versioned symbols/whatever is
necessary, but it is the correct solution and you can certainly strive
for it.

Re: Questions to testing/unstable

[Henrique de Moraes Holschuh]

On Mon, 07 May 2001, Michael Meskes wrote:
> On Mon, May 07, 2001 at 01:51:12PM -0300, Henrique de Moraes Holschuh wrote:
> > Most of us don't bother too much with testing, unless we're trying to get
> > something into testing for one particular reason or another (such as, the
> > package in testing is too damn buggy, or has a security hole).
> 
> Whow! Now that is a great explanation. We started testing for a reason. If
> all of us think that way we can as well stop using testing at all, as it

Please see my reply to Hebert Xu, later on the thread.

> will only contain packages from the old stable and some that are just
> developing to slowly to remain in quarantine.

That's not the only problem that holds packages out of testing. Check the
output of the testing scripts, and see how many are held due to dependency
problems as opposed as to being 'too new'.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


pgpb4GfEzsWkr.pgp
Description: PGP signature

Re: Questions to testing/unstable

[Henrique de Moraes Holschuh]

On Tue, 08 May 2001, Herbert Xu wrote:
> Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> > Most of us don't bother too much with testing, unless we're trying to get
> > something into testing for one particular reason or another (such as, the
> > package in testing is too damn buggy, or has a security hole).
> 
> 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.

That's why I don't bother with testing, unless I'm dealing with a urgency
high or critical upload; In that case I'll happily request the version of
the package in testing to be *removed*.

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. As soon as it gets moved into testing, I'd upload a
urgency critical package built in a proper sid chroot, and restore the bugs
to their proper severity.

Xu, I don't claim to understand your packages better than you. I have no
idea where on the dependency chain they are; maybe they don't affect other
packages in testing at all. But that's not the case for my packages.

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.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


pgpIrSD323rz0.pgp
Description: PGP signature

Re: Questions to testing/unstable

[Andreas Metzler]

Paul Martin <[EMAIL PROTECTED]> wrote:
>> Possible scenario:
>> 1.0-3 has some major changes and accidentially fixes an RC-bug in
>> 1.0-2, before _anybody_ noticed it in 1.0-2.
>> 1.0-2 goes into testing and BLAM.

> Surely, the maintainer can then close (or downgrade) the RC bug, saying
> it's fixed in the newer version?

> (Or are you meaning that the maintainer will have to play whack-a-mole
> with multiple identical RC bug entries to get the package into testing?)

Obviously it is impossible to understand my english, the points I
wanted to make were:
-Once 1.0-3 is in sid, 1.0-2 is removed from sid and nobody uses it
 anymore.
-You cannot test 1.0-2 by using 1.0-3, there can be _unknown_ bugs in
 1.0-2 which are not in 1.0-3 and vice versa.
cu andreas
-- 
Uptime: 10 seconds  load average: 0.00, 0.00, 0.00
vim:ls=2:stl=***\ Sing\ a\ song.\ ***

Re: Questions to testing/unstable

[Paul Martin]

On Tue, May 08, 2001 at 07:34:32AM +, Andreas Metzler wrote:

> Possible scenario:
> 1.0-3 has some major changes and accidentially fixes an RC-bug in
> 1.0-2, before _anybody_ noticed it in 1.0-2.
> 1.0-2 goes into testing and BLAM.

Surely, the maintainer can then close (or downgrade) the RC bug, saying
it's fixed in the newer version?

(Or are you meaning that the maintainer will have to play whack-a-mole
with multiple identical RC bug entries to get the package into testing?)

-- 
Paul Martin <[EMAIL PROTECTED]>


pgpSZLWVWEobL.pgp
Description: PGP signature

Re: Questions to testing/unstable

[Herbert Xu]

Wichert Akkerman <[EMAIL PROTECTED]> wrote:
> Previously Anthony Towns wrote:
>> That's not true at all. It's quite possible (although probably a little
>> unlikely) to maintain your packages from a box running stable, if you like.

> I'ld rather not see people do that: it means we'll also be stuck with
> using old libraries when much newer ones might be available. Look
> at the total mess with different ncurses versions in potato for example.

Just because someone is running unstable, it doesn't mean that they're
compiling against the new -dev packages.  Other things need to be done
to force people to upgrade, e.g., check build-time dependencies and/or
file bug reports.

In the case of ncurses, if someone bothered to file bug reports and/or do
NMUs, it would've been much better.  In the end it was apathy more than
anything else.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Questions to testing/unstable

[Wichert Akkerman]

Previously Anthony Towns wrote:
> That's not true at all. It's quite possible (although probably a little
> unlikely) to maintain your packages from a box running stable, if you like.

I'ld rather not see people do that: it means we'll also be stuck with
using old libraries when much newer ones might be available. Look
at the total mess with different ncurses versions in potato for example.

Wichert.

-- 
   
 / Generally uninteresting signature - ignore at your convenience  \
| [EMAIL PROTECTED]  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: Questions to testing/unstable

[Petr Cech]

On Tue, May 08, 2001 at 07:29:31PM +1000 , Anthony Towns wrote:
> On Tue, May 08, 2001 at 11:05:49AM +0200, Petr Cech wrote:
> > On Tue, May 08, 2001 at 06:42:33PM +1000 , Herbert Xu wrote:
> > > FWIW, I do all my development under testing.  I virtually ignore unstable
> > > unless I need a specific package from it.
> > but autobuilders will still compile with unstable, so it's really useless
> > (even dangerous) to upload i386 build on woody, when autobuild packages are
> > unstable.
> 
> That's not true at all. It's quite possible (although probably a little
> unlikely) to maintain your packages from a box running stable, if you like.

that depends. If I need libc6, X and gtk maybe, but you really loose on
apache, sablot (I need to kick the maintaner for the stupid shlibs, IMHO).
Or the ssl fiasco. I´ve had unstable package made uninstallable day after I
uploaded it with compiled latest unstable. Now, should I let the package
there - no, because mostly the new upload also deletes the one I compiled
with and so there is NO way to get that upload into testing

The same if, if I would compile with woody - it made the package
uninstallable on sid and I would have to pray that the hacked build-depends,
what were made according the status of woody, when I uploaded was still
valid when autobuilders get around to rebuild. Of course I loose unstable
for that. The result? The package is not in testing and not installable in
unstable

Petr Cech
-- 
Debian GNU/Linux maintainer - www.debian.{org,cz}
   [EMAIL PROTECTED]

 We Are Debian.  You Will Be Packaged. Media Opinion Is Irrelevant.

Re: Questions to testing/unstable

[Anthony Towns]

On Tue, May 08, 2001 at 11:05:49AM +0200, Petr Cech wrote:
> On Tue, May 08, 2001 at 06:42:33PM +1000 , Herbert Xu wrote:
> > FWIW, I do all my development under testing.  I virtually ignore unstable
> > unless I need a specific package from it.
> but autobuilders will still compile with unstable, so it's really useless
> (even dangerous) to upload i386 build on woody, when autobuild packages are
> unstable.

That's not true at all. It's quite possible (although probably a little
unlikely) to maintain your packages from a box running stable, if you like.
It's certainly okay to run from a somewhat out-of-date unstable box, and
that's essentially what testing ends up being. Some parts are obvious more
out of date than others, though.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
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)


pgp7JrrzQmXe9.pgp
Description: PGP signature

Re: Questions to testing/unstable

[Petr Cech]

On Tue, May 08, 2001 at 06:42:33PM +1000 , Herbert Xu wrote:
> Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> 
> > Most of us don't bother too much with testing, unless we're trying to get
> > something into testing for one particular reason or another (such as, the
> > package in testing is too damn buggy, or has a security hole).
> 
> FWIW, I do all my development under testing.  I virtually ignore unstable
> unless I need a specific package from it.

but autobuilders will still compile with unstable, so it's really useless
(even dangerous) to upload i386 build on woody, when autobuild packages are
unstable.

Also there are problems with library dependencies. Should I let rot a
package in unstable uninstallable, just because I hope it will make it in
month or two into testing? No way!

Petr Cech
-- 
Debian GNU/Linux maintainer - www.debian.{org,cz}
   [EMAIL PROTECTED]

 Debian - It is all about choice, baby!!

Re: Questions to testing/unstable

[Petr Cech]

On Mon, May 07, 2001 at 08:25:53PM +0200 , Michael Meskes wrote:
> > Most of us don't bother too much with testing, unless we're trying to get
> > something into testing for one particular reason or another (such as, the
> > package in testing is too damn buggy, or has a security hole).
> 
> Whow! Now that is a great explanation. We started testing for a reason. If

yes. and some of us gave up on testing. If I could do anything with it, I
would. But as it's now I can safely ignore it

Petr Cech
-- 
Debian GNU/Linux maintainer - www.debian.{org,cz}
   [EMAIL PROTECTED]

"Computers are useless. They can only give answers."Pablo Picasso

Re: Questions to testing/unstable

[Herbert Xu]

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:

> Most of us don't bother too much with testing, unless we're trying to get
> something into testing for one particular reason or another (such as, the
> package in testing is too damn buggy, or has a security hole).

FWIW, I do all my development under testing.  I virtually ignore unstable
unless I need a specific package from it.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Questions to testing/unstable

[Andreas Metzler]

Michael Meskes <[EMAIL PROTECTED]> wrote:
[snip]
> Why isn't it possible to move 1.0-2
> after one week even though 1.0-3 exists in unstable?

Hello!
Because 1.0-2 was not tested properly. After 1.0-3 is released nobody
uses 1.0-2 anymore, bugs in 1.0-2 but not in 1.0-3 won't be found.

Possible scenario:
1.0-3 has some major changes and accidentially fixes an RC-bug in
1.0-2, before _anybody_ noticed it in 1.0-2.
1.0-2 goes into testing and BLAM.
 cu andreas
-- 
Uptime: 10 seconds  load average: 0.00, 0.00, 0.00
vim:ls=2:stl=***\ Sing\ a\ song.\ ***

Re: Questions to testing/unstable

[Michael Meskes]

On Mon, May 07, 2001 at 01:51:12PM -0300, Henrique de Moraes Holschuh wrote:
> Developers are supposed to know what they're doing with the urgency field.
> It can be used to decrease the quarantine time of a particular upload (and
> all subsequent ones until the package manages to get installed in testing).

Okay. Thanks for explaining this.

> Most of us don't bother too much with testing, unless we're trying to get
> something into testing for one particular reason or another (such as, the
> package in testing is too damn buggy, or has a security hole).

Whow! Now that is a great explanation. We started testing for a reason. If
all of us think that way we can as well stop using testing at all, as it
will only contain packages from the old stable and some that are just
developing to slowly to remain in quarantine.

I think the ide was to constantly work on the new stable release. To do that
we have to keep testing in the mix. Why isn't it possible to move 1.0-2
after one week even though 1.0-3 exists in unstable?

Michael

-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

Re: Questions to testing/unstable

[Julian Gilbey]

On Mon, May 07, 2001 at 02:49:36PM +0200, Michael Meskes wrote:
> Let's say it takes one week for a package to make it from unstable to
> testing. So what happens if package foo_1.0-1.deb is in testing and
> foo_1.0-2.deb is uploaded and then after five days foo_1.0-3.deb is uploaded
> to unstable. What happens if no grave bug exists againts foo? Is 1.0-2 moved
> to testing after 7 days, or is 1.0-3 moved or do the seven days start anew
> with the upload of 1.0-3? The latter holds if there was a grave bug in
> 1.0-1.

Have to have 10 clear days with the current unstable package in
unstable.  Otherwise, the package which is being proposed for moving
into testing won't have had 10 days of testing.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

 Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
   Debian GNU/Linux Developer,  see http://people.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Re: Questions to testing/unstable

[Henrique de Moraes Holschuh]

On Mon, 07 May 2001, Michael Meskes wrote:
> to unstable. What happens if no grave bug exists againts foo? Is 1.0-2 moved
> to testing after 7 days, or is 1.0-3 moved or do the seven days start anew

The quarantine time is restarted every upload.

> If it is also true with no grave bug, we should encourage developers to wait
> a week between two uploads or else their software won't make it into
> testing.

Developers are supposed to know what they're doing with the urgency field.
It can be used to decrease the quarantine time of a particular upload (and
all subsequent ones until the package manages to get installed in testing).

> wouldn't be suprised if the maintainers didn't even notice that. For

Most of us don't bother too much with testing, unless we're trying to get
something into testing for one particular reason or another (such as, the
package in testing is too damn buggy, or has a security hole).

There are only so many hours in a day, you see.

> instance webmin does not seem to have a release critical bug but it's not in
> testing at all.

This is usually caused by dependencies. A package cannot move into testing
if the packages it depends on are not in testing (or being moved into
testing as well).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


pgpJ0CNBNxFLH.pgp
Description: PGP signature