Ian, (IANADD(Y)), but part of me wonders if this isn't the behavior we want; most debian users have come to expect their debian-supplied packages to behave a certain way. Allowing the packages to break that 'certain way' with a one-line entry in the .changes file seems to be opening the floodgates.
I think I would be more welcoming if I saw an example or two of programs that were kept out of the archives, along with the accompaning (sp?) errors that did indeed look rather silly. One thought I have -- simple errors ought to be simple fixes. Fundamental errors require fundamental fixes -- the lintian exception list. Perhaps an extension to this idea, along the lines of the package 'pool' -- allow the tools to decide what level of lintian errors they are willing to install. One could have a lintian-pristine OS, one with limited errors, and one that didn't care how messy things got. I don't know if I prefer that or not. Hehehe. $0.002. :) Thanks Ian! :) On Thu, Jan 13, 2000 at 12:30:45AM +0000, Ian Jackson wrote: > Package: debian-policy, > > I'm not sure quite what package to submit this under, but I think we > have a problem. > > Current arrangements are that you can't upload new packages which have > lintian errors. I don't think this is correct, because packages which > have lintian errors might still be an asset to the distribution. > > However, clearly we can't expect the FTP archive maintainers to > personally decide whether each error or bug is important enough to > prevent a package's inclusion. They need a procedural way to do this > (and the need for such a procedural check is how the `no lintian > errors' requirement got there in the first place). > > Also, we can't expect the lintian maintainer (or the maintainer of > some other automatic checking software) to keep abreast of every > possible exception and/or possible bug in policy or lintian. > Certainly we shouldn't put the lintian maintainer on the critical path > for getting random packages included in the distribution. > > So, let us step back and bit and see what we mean when we find that > lintian reports an error with a package. There are a number of > possibilities: > > * The package is simply buggy. If the error is severe enough (eg, if > it is release-critical) then it should be rejected; otherwise it > should go through but we would like to know that a bug report had been > submitted. > > * The package has some special quirk which means it has to do > something which lintian thinks is a bug. I understand that lintian > has an exception list for this case, so this is a bug in the lintian > exception list. Again, we'd like to know that the maintainer knew > about it and a bug had been submitted. > > * The package maintainer disagrees with policy and is pursuing the > matter through the policy group, or appealing to the technical > committee, or something. In this case probably the package should be > accepted in the meantime. The maintainer has presumably weighed up > the consequences of installing the package despite its policy > violation. But, we would like to know that the maintainer was aware > of the policy violation, and that a bug was open against policy. > > There are probably a few more rare cases, but I think my proposed > exception mechanism will handle them all. > > You'll notice that the common thread running through these cases is > that it's usually OK to include the package if the maintainer knew > about the problem and a bug is open. So, I propose that we give the > maintainer a way of saying `I know about this and it's a filed as a > bug'. > > This would take the form of a `Known-Problems' field in the .changes > file. Initially this would be an X-C-Known-Problems so that old > versions of dpkg-dev can build packages; the archive script would > understand both. The syntax would be something like > > X-C-Known-Problems: > #3923 lintian E: binary-without-manpage ls > #4000 lintian E: postinst-does-not-set-usr-doc-link > > (I forget the exact format of Lintian error messages.) The idea is > that the archive maintenance software knows that the maintainer > expects that lintian error, and quotes the relevant BTS number. The > string `lintian' is included in case we develop any new checking > software. The archive maintenance script would know that a lintian > `E:' is an error which should correspond to an open bug of at least > severity normal and would check this. > > We also need a way for lintian to distinguish errors which should > correspond to normal severity bugs, and which correspond to > release-critical bugs. The latter should be rare. I'd suggest that a > new C: prefix be defined for critical errors, which the archive > maintenance script would check corresponded to a bug which was > important or more severe. > > Ian. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- Seth Arnold | http://www.willamette.edu/~sarnold/ Hate spam? See http://maps.vix.com/rbl/ for help Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
