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 packages. 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 it. > 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 this. Scott [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