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

Re: Processed: breaking the build of other packages is RC

On Mon, 2004-06-07 at 01:55 +0200, Adrian Bunk wrote:

> On Sun, Jun 06, 2004 at 04:19:41AM +0100, Scott James Remnant wrote:
> > No... making *unrelated* software is release critical, and warrants a
> > "critical" severity instead of "grave".  grave is defined as:
> > 
> > 	makes the package in question unusable or mostly so, or causes
> > 	data loss, or introduces a security hole allowing access to the
> > 	accounts of users who use the package.
> > 
> > none of which describe this bug.  "important" is the appropriate
> > severity (in fact, it could be argued that "normal" is the appropriate
> > severity, but I personally like to keep libtool-caused FTBFS bugs at
> > important until I've thoroughly checked them myself).
> If a FTBFS in a package is RC, it would be very strange if an update of 
> build dependency package that causes a buld failure wasn't RC...
This seems logical, except by inference you've just made almost every
bug in a tool-chain or build-system package Release Critical, which
would make the BTS vastly non-useful for those of us who maintain such

When filing bugs, there seems to be a tendency for some people to shove
the severity as high as it will go without toppling over.  This is
usually counter-productive -- severities should be considered relative
to the package you are filing against and if in doubt "normal".

This doesn't mean you shove all (eg. gcc) bugs in as "grave" or
"critical", it means you use "normal" or perhaps "important" in cases
where something that worked before has stopped working.  Only use higher
severities such as "grave" where the bug is causing most of the archive
to not build, or something.

As for FTBFS themselves, you appear to be misunderstanding *why* they're
filed at the level they are filed at.  Being unable to even *build* a
package falls under "makes the package in question unusable or mostly
so".  We only ever release packages with the same version on all
architectures[0], so having the latest unstable release simply
unbuildable does make that a Release Critical issue *for that package*.

We don't, however, take build dependencies into account when preparing a
release.  Britney doesn't guarantee that testing is buildable, a package
can be placed in stable without its necessary build-depends.

So this makes the issue of how to deal with a package whose FTFBS is
caused by a build-depend a slightly interesting one.  In the end, one
can always use the previous version of the build-depend and upload with
that, close the FTBFS bug and open a new one or reassign with a
different title and severity against the build-depend package.

As I've stated, my personal preference for "it breaks one or two
packages that work with the older version" is the 'important' severity.

This "friendly" approach doesn't even apply for Libtool though, it
should never be a build-depend -- the necessary files should be included
in the package.  All the package has to do is roll back, upload a new
version and fix the bug.  A separate bug can be opened at the lower
severity against Libtool.

> Besides this, there might be other packages that FTBFS because of this 
> problem.
I haven't heard of any; and this is precisely why that bug is still
open, to allow them to come forward and say "this breaks me too!"

> > Folks, please stop artificially inflating bug severities in an attempt
> > to get them noticed and/or fixed quicker.  Most good maintainers are
> > likely to have far better an idea of a bug's true severity/urgency than
> > anyone passing through the BTS.
> Most good maintainers would likely have tried to solve this bug during 
> the last two months...
Ooh, flamage!  Most good maintainers don't resign in a tantrum every few
months either :o)

I'm only human, I have a day-job as well as a social life -- so I can't
deal with every minor problem that promptly.  I do my best, but
sometimes things take a while to get to.

That isn't the case here though, I'm deliberately leaving Libtool alone
at the moment.  The changes to the dependency_libs and ltdl are fairly
major "assumption" ones, so to me it makes sense to sit back for a bit
and see what they break and then deal with them all in one go.  A couple
of unrelated new bugs might get delayed because of this wait, but
there's method to my madness.

Beware kids, when you reassign a bug to a build-depend, if your package
is the only one that breaks you're likely to have a long wait while a
maintainer waits for more reports to decide what do do about it.

> > In fact, this bug looks to need reassigning back to net-snmp because
> > that package isn't linking its shared libraries properly; but I haven't
> > had time to investigate fully, so haven't done that yet.
> The problem is a dependency cycle in two libraries in net-snmp.
Really?  Feel free to reassign that back to net-snmp and fix it then.
Those are explicitly not supported by Libtool and never have been.  I'm
going to wait to do by own analysis before doing anything, but if you're
sure you know what the problem is with net-snmp, by all means deal with

> And I don't any warning in the libtool 1.5.4 documentation mentioning
> that this change was intentional.
*shrug* that depends what's caused the breakage.  iirc the upstream
1.5.2 -> 1.5.4 changes were largely cosmetic from a Linux POV.  There
was a major bug fix of mine in there, but I'm not sure that'd cause


[0] I expect there have been exceptions to this, but anyhoo
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: