Re: packages affected list for must changes to policy (was: Re: Bug#91257: [PROPOSED] changes to X font policy)
On Mon, Mar 26, 2001 at 09:35:36AM -0600, Steve Greenland wrote: On 25-Mar-01, 04:26 (CST), Anthony Towns aj@azure.humbug.org.au wrote: If you create a must directive, then you've just created a reason to have a number of extra RC bugs. Indeed, that's the only point of making it a must instead of a should. The point of making a must requirement is that the consequences of not following that requirment are sufficiently serious to justify removing a package that does not follow that requirement. The number of packages affected is largely irrelevant. There are two reasons for removing packages that don't meet a policy guidelines: either that it causes breakage that's considered RC anyway, or that it causes an inconsistency that we don't like. The requirement that games not be made setuid is an example of the first case, the requirement that packages follow the FHS would be an example of the latter. The number of packages affected definitely matters for the latter case: if our mandate is mainly to document existing practice, then it seems a bit inappropriate to insist upon a consistency that doesn't already exist. If I propose that packages must not call 'rm -rf /' in their postinst script, we could all agree that it was a completely reasonable requirement no matter how many packages were affected. Certainly. A proposal that all packages must have docs in /usr/share/doc not /usr/doc, OTOH, wouldn't be. In the rm -rf / case, though, it's still relevant how many packages are affected, if only in so far as to argue but no one does this anyway, and it's obviously stupid, what's the point of putting it in policy?. If you're not going to bother filing the RC bugs, there's no reason not to leave it as a should. If you are going to file the RC bugs, then someone's got to figure out which packages it applies to at some point anyway. There's a huge difference between you have to find all the affected packages and someone (probably many people) will have to find the affected packages. In the end it comes down to me having to look through every such report and make a decision on it though, so it's not that different. Better to be informed before the fact than after, IMO. Better to have the proposers work out what'll be affected for each of their respective proposals, than me or Jordi have to work out what'll be affected by every proposal too. Are you also going to require that each person who suggests a modification to a proposal adjust the list appropriately? And who gets to keep up with checking the new packages every day? Geez, I never suggested being dictatorial about it. If there's one or two false negatives, it's not the end of the world. But sure, if someone modifies the proposal they should try to understand the effect of that modification, if the result's going to change whether we're willing to release some package or not. Because people don't seem to understand the point of the must/should dichotomy. The must/should dichotomy is (or at least should be) based on the real consequences of not following a recommendation. Indeed. People seem to think it's not relevant what happens if you don't follow the recommendation though, because of course, if it's a must, everyone will follow it, so clearly no packages are affected. [0] That's mostly why I'd like to see lists of packages that currently don't follow the recommendation, though: that way you can see some real examples of exactly what happens if the guideline isn't followed, and you can see how many packages will be pulled if you get too busy to do NMUs and the maintainers don't get around to fixing it themselves. Encouraging people to list the packages which'll have RC bugs filed against them due to a proposal they're making doesn't seem particularly drastic. Encouraging I could agree with, particularly when the check could be automated against the Packages file. But even an automated check against the maintainer scripts is not feasible for most people, and a lot of checks are not possible to automate. A lot of checks are possible to automate: just have a look at lintian some time. And there should be at least three people behind every policy proposal anyway (a proposer and two seconds), at least *one* of whom out to be able to give some sort of indication what packages will be affected. Cheers, aj [0] http://lists.debian.org/debian-policy-0103/msg00088.html http://lists.debian.org/debian-policy-0103/msg00312.html -- Anthony Towns [EMAIL PROTECTED] 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) pgp83fQq7xpJS.pgp Description: PGP signature
Re: packages affected list for must changes to policy (was: Re: Bug#91257: [PROPOSED] changes to X font policy)
On 27-Mar-01, 23:57 (CST), Anthony Towns aj@azure.humbug.org.au wrote: On Mon, Mar 26, 2001 at 09:35:36AM -0600, Steve Greenland wrote: Encouraging I could agree with, particularly when the check could be automated against the Packages file. But even an automated check against the maintainer scripts is not feasible for most people, and a lot of checks are not possible to automate. A lot of checks are possible to automate: just have a look at lintian some time. Lintian has access to the entire package contents. I only have access to the Packages file(s) and the contents of the packages that I've installed locally. (Which would, admittedly, let me check pretty much everything in standard and higher.) Hmmm, is there anywhere generally available to Debian developers that has all the packages unpacked? So that one could grep all the maintainer scripts or init.d scripts, for example. I suspect I took your original suggestion as a proposed requirement, which I think is unreasonable. As it would be nice if people did this, I have no objection, of course. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: packages affected list for must changes to policy (was: Re: Bug#91257: [PROPOSED] changes to X font policy)
On 25-Mar-01, 04:26 (CST), Anthony Towns aj@azure.humbug.org.au wrote: If you create a must directive, then you've just created a reason to have a number of extra RC bugs. Indeed, that's the only point of making it a must instead of a should. The point of making a must requirement is that the consequences of not following that requirment are sufficiently serious to justify removing a package that does not follow that requirement. The number of packages affected is largely irrelevant. If I propose that packages must not call 'rm -rf /' in their postinst script, we could all agree that it was a completely reasonable requirement no matter how many packages were affected. If you're not going to bother filing the RC bugs, there's no reason not to leave it as a should. If you are going to file the RC bugs, then someone's got to figure out which packages it applies to at some point anyway. There's a huge difference between you have to find all the affected packages and someone (probably many people) will have to find the affected packages. Are you also going to require that each person who suggests a modification to a proposal adjust the list appropriately? And who gets to keep up with checking the new packages every day? Because people don't seem to understand the point of the must/should dichotomy. The must/should dichotomy is (or at least should be) based on the real consequences of not following a recommendation. The bug system severities are just there to make it easier to track. Encouraging people to list the packages which'll have RC bugs filed against them due to a proposal they're making doesn't seem particularly drastic. Encouraging I could agree with, particularly when the check could be automated against the Packages file. But even an automated check against the maintainer scripts is not feasible for most people, and a lot of checks are not possible to automate. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
packages affected list for must changes to policy (was: Re: Bug#91257: [PROPOSED] changes to X font policy)
* Anthony Towns aj@azure.humbug.org.au [010325 01:11]: BTW, I'm inclined to think it'd be a good idea for people who want to add a must requirement (or to change a should to a must) to include a list of packages that would need to be removed from the distribution due to the change. Anyone agree/disagree? While I appreciate your desire to increase understanding of consequences of policy changes, asking every policy change author to examine the details of `apt-cache pkgnames | wc -l` packages (on my machine, 8458 packages!) is .. well, assume someone can check each package in an average of one second, that would still take nearly two and a half hours of otherwise productive time. If examining each package took a more reasonable ten seconds, that is a whole day's work spent to find which packages will need to change to stay in the distribution. Why don't you like the current system? I have thought the proposal / vote process will keep arbitrary changes out of policy, and a package maintainer is free to change bugs against his or her package to be against policy with a note stating why compliance is difficult for his or her package. If it turns out to be too difficult for a package to comply with policy, fine, re-amend policy if the package is important enough to keep despite non-compliance. Furthermore, with releases as far apart as they are, maintainers have an average of six to eight months to fix problems with their packages.[1] I would hope something could be worked out in that time frame. I don't see anything drastically wrong with the current process. Why do you disagree with it? Cheers [1]: Yes, statistically speaking, half the time between releases. Individual cases, with individual changes, could range between 16 months to less than a day, but I doubt many policy changes are going to be made in the days before a release. -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Re: packages affected list for must changes to policy (was: Re: Bug#91257: [PROPOSED] changes to X font policy)
On Sun, Mar 25, 2001 at 01:46:59AM -0800, Seth Arnold wrote: * Anthony Towns aj@azure.humbug.org.au [010325 01:11]: BTW, I'm inclined to think it'd be a good idea for people who want to add a must requirement (or to change a should to a must) to include a list of packages that would need to be removed from the distribution due to the change. Anyone agree/disagree? While I appreciate your desire to increase understanding of consequences of policy changes, asking every policy change author to examine the details of `apt-cache pkgnames | wc -l` packages (on my machine, 8458 packages!) is .. ...completely unrelated to what I'd like. If you create a must directive, then you've just created a reason to have a number of extra RC bugs. Indeed, that's the only point of making it a must instead of a should. If you're not going to bother filing the RC bugs, there's no reason not to leave it as a should. If you are going to file the RC bugs, then someone's got to figure out which packages it applies to at some point anyway. There's 6720 packages in sid/i386 at the moment, btw, not 8458. Why don't you like the current system? Because people don't seem to understand the point of the must/should dichotomy. I don't see anything drastically wrong with the current process. Why do you disagree with it? Encouraging people to list the packages which'll have RC bugs filed against them due to a proposal they're making doesn't seem particularly drastic. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] 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) pgp3hooyFWwNC.pgp Description: PGP signature
Re: packages affected list for must changes to policy (was: Re: Bug#91257: [PROPOSED] changes to X font policy)
* Anthony Towns aj@azure.humbug.org.au [010325 02:30]: If you're not going to bother filing the RC bugs, there's no reason not to leave it as a should. If you are going to file the RC bugs, then someone's got to figure out which packages it applies to at some point anyway. This makes sense if one assumes that the only way packages will be brought into alignment with policy is by filing bugs; it ignores debian maintainers who read the changes to policy and change their packages without having bugs filed against their packages. (If no one does this, let me know, and I'll shutup. :) It also assumes that the only person to bother filing bugs is the proposer. Don't forget that Joe Standard User gets involved in the process too (once a proposed change has been accepted). More eyes etc. There's 6720 packages in sid/i386 at the moment, btw, not 8458. Thanks for the correction. At ten seconds per package, this is still nearly nineteen hours though. Why don't you like the current system? Because people don't seem to understand the point of the must/should dichotomy. Fair enough. However, what is the purpose of 'must' if the amount of work required to put one in place is probably beyond anyone's available time? Encouraging people to list the packages which'll have RC bugs filed against them due to a proposal they're making doesn't seem particularly drastic. If the proposal is being made in response to the behavior of several packages that have irked the proposer, I think I would have to agree that those packages should be listed -- perhaps as support for the proposed policy change. :) I agree with the idea that an example list of packages affected is a Good Thing; but I am still unconvinced that every policy change involing a 'must' must involve a possibly lengthy exhaustive search through all available packages. Cheers :) -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Re: packages affected list for must changes to policy (was: Re: Bug#91257: [PROPOSED] changes to X font policy)
Seth Arnold [EMAIL PROTECTED] writes: * Anthony Towns aj@azure.humbug.org.au [010325 02:30]: There's 6720 packages in sid/i386 at the moment, btw, not 8458. Thanks for the correction. At ten seconds per package, this is still nearly nineteen hours though. Luckily we have these marvellous contraptions called computers which are capable of performing boring, repetitive tasks over and over and over with a minimum of fuss on the part of the operator. I wish there was a program which would have this debate automatically. I think Anthony's proposal is sound and makes good sense. If someone cannot be bothered to check even how many (let alone which) packages will be affected by a proposal which will create more RC bugs, then I'm not sure how useful it would be to make it a `must' instead of a `should'. jason -- 4. A SIMIAN should respond to a TYPE or FASTER request with an ACCEPT code, especially if there are deadlines. The only other allowed responses are REFUSE, ASLEEP, GONE, NORESPONSE, or DEAD.
Re: packages affected list for must changes to policy (was: Re: Bug#91257: [PROPOSED] changes to X font policy)
On Sun, Mar 25, 2001 at 09:39:56PM +1000, Jason Parker wrote: Seth Arnold [EMAIL PROTECTED] writes: * Anthony Towns aj@azure.humbug.org.au [010325 02:30]: There's 6720 packages in sid/i386 at the moment, btw, not 8458. Thanks for the correction. At ten seconds per package, this is still nearly nineteen hours though. Luckily we have these marvellous contraptions called computers which are capable of performing boring, repetitive tasks over and over and over with a minimum of fuss on the part of the operator. Further to this: ] [EMAIL PROTECTED]:~$ zgrep 'usr/X11R6/lib/X11/fonts' woody/Contents-i386.gz | ] sed 's/^.* //;s,.*/,,' | sort -u fontpkgs.lst ] [EMAIL PROTECTED]:~$ zgrep 'bin/' woody/Contents-i386.gz | sed 's/^.* //;s,.*/,,' | ] sort -u binpkgs.lst ] [EMAIL PROTECTED]:~$ comm -1 -2 binpkgs.lst fontpkgs.lst ] bitchx ] cmatrix ] dosemu ] tilp ] x3270 ] xawtv ] xtel bitchx provides: /usr/X11R6/lib/X11/fonts/misc/vga11x19.pcf.gz /usr/X11R6/lib/X11/fonts/misc/default8x16.pcf.gz /usr/bin/bitchx cmatrix provides: /usr/X11R6/lib/X11/fonts/misc/mtx.pcf /usr/bin/cmatrix dosemu provides: /usr/X11R6/lib/X11/fonts/misc/vga.pcf.gz /usr/bin/xdos tilp provides: /usr/X11R6/lib/X11/fonts/misc/ti_calcs.pcf.gz /usr/bin/tilp x3270 provides: /usr/X11R6/lib/X11/fonts/misc/3270-12.pcf.gz /usr/X11R6/lib/X11/fonts/misc/3270-12b.pcf.gz /usr/X11R6/lib/X11/fonts/misc/3270-20.pcf.gz /usr/X11R6/lib/X11/fonts/misc/3270-20b.pcf.gz (and others) /usr/X11R6/bin/x3270 xawtv provides: /usr/X11R6/lib/X11/fonts/misc/led-fixed.pcf /usr/X11R6/bin/xawtv xtel provides: /usr/X11R6/lib/X11/fonts/misc/xteldigit.pcf.gz /usr/bin/xtell This doesn't cover non-US/*, and it mightn't be complete for main/contrib/non-free, but it doesn't exactly take 20 hours... Providing a patch for lintian would be even better, of course, but something like the above would suffice as far as I'm concerned. Actually, it isn't complete for main/contrib/non-free: nethack didn't show up because it keeps its binary in /usr/games. Packages like it are: cxhextris jnethack nethack A brief search of those packages' bug pages only turns up the following font related bugs: #38425: x3270: x3270,WindowMaker /usr/X11R6/lib/X11/fonts/misc:unscaled segfault #89095: cmatrix doesn't run update-fonts-alias on postrm There weren't any bugs that I could see about fonts in a binary package. There's already a should directive, so there's justification for them even without the must. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] 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) pgpSdg2YXKbrA.pgp Description: PGP signature
