Re: Finishing the FHS transition
Chris Waters [EMAIL PROTECTED] wrote: On Sun, May 06, 2001 at 07:31:43PM +0200, Adrian Bunk wrote: - A change in the policy to remove the obsolete /usr/doc symlinks. This is supposed to happen once enough packages make the transition. Now, if we're really down to 253 packages that use /usr/doc (with no symlink), then maybe it's time. But, unfortunately, that number, 253, measures *claimed* compliance, not actual compliance. Now, my poking around suggests that there are actually far *fewer* than 253 packages still using /usr/doc. And if that's true, then it's definitely time to remove the symlinks. But it might be nice to have some hard facts, rather than speculation based on unreliable claims made by inattentive package maintainers. http://qa.debian.org/fhs.html ... which is down to 109 /usr/doc-using packages on i386. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Finishing the FHS transition
Seth == Seth Arnold [EMAIL PROTECTED] writes: Seth Is this working under the assumption that the release manager will drop Seth all packages not recent enough when freezing? The assumption is that the release manager shall come up with whatever criteria seem reasonable to him for release, and we shall not tweak informative fields in an attempt to indirectly determine what goes into a release independent of actual performance and conformance to the normative aspects of the policy document. manoj -- You will be dead within a year. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Finishing the FHS transition
On Sun, 6 May 2001, Chris Waters wrote: This is supposed to happen once enough packages make the transition. Now, if we're really down to 253 packages that use /usr/doc (with no symlink), then maybe it's time. But, unfortunately, that number, 253, measures *claimed* compliance, not actual compliance. Now, my poking around suggests that there are actually far *fewer* than 253 packages still using /usr/doc. And if that's true, then it's definitely time to remove the symlinks. But it might be nice to have some hard facts, rather than speculation based on unreliable claims made by inattentive package maintainers. Actually, I already did a mass bug filing, on the usr/doc issue(did a grep on Contents-i386, which wasn't fully accurate(other archs, stale data(up to a week or so))). I have seen several of the bugs closed, probably more than half now. I need to do another scan, to see where we stand on that.
Re: Finishing the FHS transition
On Sun, 6 May 2001, Joey Hess wrote: Chris Waters wrote: - A change in the policy to remove the obsolete /usr/doc symlinks. This is supposed to happen once enough packages make the transition. No, it is supposed to happen one release _after_ a release in which all the packages have made the transition. So sarge at the earliest, not woody. Um, when was it decided that woody+1=sarge? When was this flamewar?
Re: Finishing the FHS transition
On Sun, 6 May 2001, Chris Waters wrote: Didn't we already have this discussion? The Standards-Version field is not a reliable indication of much of anything. I strongly object Policy says: Policy says doesn't make the packages comply. And you can file all the bugs reports you want, but that doesn't magically fix the packages. And until they're fixed, you can't use them as a reliable indicator of FHS compatibility. QED. Standards-Version 3 : a not FHS compliant package is at most a normal bug Standards-Version = 3: a not FHS compliant package is at most a serious bug We have many packages with old Standards-Versions which actually comply with newer standards and *are* FHS compatible, and we have packages with newer Standards-Versions that are NOT FHS compatible. Please file RC bug on packages with Standards-Version = 3 that are not FHS compatible. I think that if you really want to focus on FHS compatibility, you're better off ignoring the Standards-Version issues for now. Its just another can of worms. Picking the minimum Standards-Version for release is something we normally do at freeze time. I think it's important that our packages follow a not too outdated policy and the Standards-Version field is the indicator for this. Freeze time is too late for picking the minimum Standards-Version for release - the right time would be shortly after the last stable was released. An example: It would be nice to have a minimum Standards-Version of 3.1 (that includes build dependencies), but you can't file 1060 RC bugs at the beginning of a freeze. ... Note that the next paragraph mentions filing bug reports if the package becomes too much out of date. If any is too much, why bother to say too much? You mustn't have to upgrade the Standards-Version field when your package doesn't comply with a more recent policy - a package that doesn't follow FHS will never rech Standards-Version 3.0 . to removing packages because of what amount to cosmetic issues, and an Where did I say that I want to remove the packages??? I said that I want to send bug reports. RC bugs mean the package must be removed from the next release if it's not fixed. Unless you can guarantee that the bugs will be fixed (i.e., you're volunteering to fix them yourself), you _are_ asking for package to be removed when you file RC bugs. These bugs are relatively easy to fix bugs and many of them will be fixed at a bug squashing party - and yes, I do fix many easy to fix bugs at each bug squashing party. But BTW: When a maintainer doesn't even when there's a RC bug starts to work on upgrading the package to comply with a policy that is nearly two years old there's the question of he's MIA. Anyway, I apologize for a reminder I'm sure you don't need. It's just a habit of mine, please forgive me. Bottom line, I think there remains a lot of work checking the subtle and not-so-obvious stuff in the FHS before we can confidently claim FHS compatibility (and even *begin* to work on actual compliance). Reading the last three sentence I'm glad to hear that you volunteer to do all this checks... ... And I think mass filings of RC bugs would be premature at best. It's perhaps really late because we are relatively close too a freeze but it's definitely not premature. cheers cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: Finishing the FHS transition
Hi Adam! You wrote: Actually, I already did a mass bug filing, on the usr/doc issue(did a grep on Contents-i386, which wasn't fully accurate(other archs, stale data(up to a week or so))). I have seen several of the bugs closed, probably more than half now. I need to do another scan, to see where we stand on that. There is already a list on http://qa.debian.org/fhs.html -- Kind regards, +---+ | Bas Zoetekouw | Si l'on sait exactement ce | || que l'on va faire, a quoi| | [EMAIL PROTECTED] | bon le faire?| |[EMAIL PROTECTED] | Pablo Picasso | +---+
Re: Finishing the FHS transition
On Mon, May 07, 2001 at 10:57:37AM +0200, Adrian Bunk wrote: Standards-Version 3 : a not FHS compliant package is at most a normal bug Standards-Version = 3: a not FHS compliant package is at most a serious bug This is not correct. You can't change the severity of a bug by twiddling a field with a purely indicative use. We have many packages with old Standards-Versions which actually comply with newer standards and *are* FHS compatible, and we have packages with newer Standards-Versions that are NOT FHS compatible. Please file RC bug on packages with Standards-Version = 3 that are not FHS compatible. No. Don't. I'll just downgrade them as soon as I see them, so you'll be just wasting your own time and mine. Policy is simply wrong in using the word must in regards to the Standards-Version field. And no, this isn't an opportunity for discussion. Everything there is to be said on this matter has been said, repeatedly. Check the -policy archives if you really must. Standards-Versions aren't release critical. You can put it as Standards-Version: 526.7.8.9.13-Foo.6 if you want. And no matter what Standards-Version you have, you still have to follow the FHS, you have to use /usr/share/doc, and if you specify build-dependencies they have to be correct. 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) pgpZV26iMQnSr.pgp Description: PGP signature
Re: Finishing the FHS transition
On Sun, May 06, 2001 at 03:52:57PM -0500, Steve Greenland wrote: Uhh, when did that become a must? In 3.5.2 the first paragraph says Probably during the policy/packaging merger. I intend at some point to go through policy and fix all of these confusions. Furthermore, it makes no sense for the issue to be talked about in two different places, either. 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: Finishing the FHS transition
Adrian == Adrian Bunk [EMAIL PROTECTED] writes: Adrian In the source package's `Standards-Version' control Adrian field, you must specify the most recent version number Adrian of this policy document with which your package Adrian complies. The current version number is 3.5.4.0. My opinion about the intent that this was meant to convey is that when you are building your package, update the standards version field to reflect what you comply with. Adrian This information may be used to file bug reports Adrian automatically if your package becomes too much out of date. I think this is a flaw in our current policy, and needs to be changed. If a package has no bugs (including policy violation bugs resulting from not following other must or should directives), then it should not need to be updated to just change the standards version field; and using the standards version field as a reason ti file bugs is just plain wrong. manoj -- What's a cult? It just means not enough people to make a minority. Robert Altman Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Finishing the FHS transition
* Manoj Srivastava [EMAIL PROTECTED] [010507 13:53]: field; and using the standards version field as a reason ti file bugs is just plain wrong. Is this working under the assumption that the release manager will drop all packages not recent enough when freezing? -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Re: Finishing the FHS transition
Adrian Bunk wrote: ... Oliver Elphick ([EMAIL PROTECTED]) libpgsql This package is obsolete and should not be included in any release. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C If it is possible, as much as it depends on you, live peaceably with all men.Romans 12:18
Re: Finishing the FHS transition
On Sun, May 06, 2001 at 07:31:43PM +0200, Adrian Bunk wrote: I want to suggest to finish the FHS transition. This includes the following steps: - Packages with Standards-Version = 3.0 must follow the FHS. Didn't we already have this discussion? The Standards-Version field is not a reliable indication of much of anything. I strongly object to removing packages because of what amount to cosmetic issues, and an incorrect Standards-Version (one that doesn't reflect the version of policy that the package _actually_ complies with) is really no more than a cosmetic issue (no software actually uses that field). I only have a few of the listed packages installed on my system, but most of the ones I checked did indeed use /usr/share/doc (and /usr/share/man, in those cases where man pages were present). I suspect that this is due to the use of debhelper, but anyway Checking for FHS violations should be done by checking for FHS violations, not by checking an unreliable and all-but-meaningless field in some configuration file. (Plus, as a side issue, by a strict reading of the FHS, we should be using /usr/share/menu rather than /usr/lib/menu, which means RC bugs against nearly every package in the system!) :-) - A change in the policy to remove the obsolete /usr/doc symlinks. This is supposed to happen once enough packages make the transition. Now, if we're really down to 253 packages that use /usr/doc (with no symlink), then maybe it's time. But, unfortunately, that number, 253, measures *claimed* compliance, not actual compliance. Now, my poking around suggests that there are actually far *fewer* than 253 packages still using /usr/doc. And if that's true, then it's definitely time to remove the symlinks. But it might be nice to have some hard facts, rather than speculation based on unreliable claims made by inattentive package maintainers. Ben Gertzfield ([EMAIL PROTECTED]) wmifs Eric Leblanc ([EMAIL PROTECTED])groovycd Eric Leblanc ([EMAIL PROTECTED])zangband Gene McCulley ([EMAIL PROTECTED]) xcopilot Javier Fernandez-Sanguino Pen a ([EMAIL PROTECTED]) spellcast Luis Francisco Gonzalez ([EMAIL PROTECTED]) xgammon Rob Browning ([EMAIL PROTECTED]) emacs20 Robert Woodcock ([EMAIL PROTECTED]) cd-discid Takuo KITAME ([EMAIL PROTECTED]) bbdb Vincent Renardias ([EMAIL PROTECTED]) gdb Vincent Renardias ([EMAIL PROTECTED]) gnumeric Wichert Akkerman ([EMAIL PROTECTED]) sed I inspected these packages. Only emacs20 lacked the /usr/share/doc directory. If that ratio holds true (which I doubt), then we've only got 21 packages left to transition! :-) cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Finishing the FHS transition
Chris Waters schrieb: (Plus, as a side issue, by a strict reading of the FHS, we should be using /usr/share/menu rather than /usr/lib/menu, which means RC bugs against nearly every package in the system!) :-) /usr/lib/menu is not shareable, since it would be most confusing to have a menu item that just doesn't work, because the package it belongs to is installed on another machine with which /usr/share is shared. ciao, 2ri -- Q: How does a Unix guru have sex? A: gunzip strip touch finger mount fsck \ more yes fsck fsck fsck umount sleep
Re: Finishing the FHS transition
On Sun, 6 May 2001, Chris Waters wrote: I want to suggest to finish the FHS transition. This includes the following steps: - Packages with Standards-Version = 3.0 must follow the FHS. Didn't we already have this discussion? The Standards-Version field is not a reliable indication of much of anything. I strongly object Policy says: -- snip -- In the source package's `Standards-Version' control field, you must specify the most recent version number of this policy document with which your package complies. The current version number is 3.5.4.0. This information may be used to file bug reports automatically if your package becomes too much out of date. -- snip -- to removing packages because of what amount to cosmetic issues, and an Where did I say that I want to remove the packages??? I said that I want to send bug reports. incorrect Standards-Version (one that doesn't reflect the version of policy that the package _actually_ complies with) is really no more than a cosmetic issue (no software actually uses that field). you must specify the most recent version number of this policy document with which your package complies: You must upgrade this field when your package complies with a more recent policy - and when your package does already comply with a more recent policy nothing more than an upload with an updated Standards-Version field is needed. I only have a few of the listed packages installed on my system, but most of the ones I checked did indeed use /usr/share/doc (and /usr/share/man, in those cases where man pages were present). I suspect that this is due to the use of debhelper, but anyway Checking for FHS violations should be done by checking for FHS violations, not by checking an unreliable and all-but-meaningless field in some configuration file. ... See above: I want to file a RC bug either because a) the package follows a too old policy or b) because it violates the _must_ in the polict that says that the Standard-Version must get updated. a) needs discussion whether we consider packages not following the FHS too much out of date, b) is a violation of the policy that doesn't need discussion - that means the only question is whether anyone disagrees that we want to have all packages in unstable to follow the FHS. cheers cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
menu and FHS (was Re: Finishing the FHS transition)
On Sun, May 06, 2001 at 09:13:26PM +0200, Arthur Korn wrote: /usr/lib/menu is not shareable Yes, it is. There's a reason why each entry starts: ?package(name) Anyway, that's not really relevent -- /usr/share is for architecture-independent static files. The FHS doesn't grant exceptions for files that would cause breakage if they actually were shared between different machines. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Finishing the FHS transition
On Sun, May 06, 2001 at 07:31:43PM +0200, Adrian Bunk wrote: If noone has a good argument against this I'll send RC bugs in one week to force the upgrade of the Standards-Version. The packages inetutils, gnumach, hurd and mig are only applicable to the Hurd, and we have not determined yet how much and what of the FHS is applicable to us. Most of it is, but we might need an appendix for the Hurd just as there is an appendix for Linux. In any way, I will bump the number if it makes you happy on my next update, and Jeff Bailey took over maintenance of GNU inetutils, he is preparing an update, but I wouldn't consider an old standards version a release critical bug. You will have to bother and check each package individually if there is actually a violation of current policy or a critical bug that warrants a release critical bug report. GNU Hurd Maintainers (bug-hurd@gnu.org) gnumach GNU Hurd Maintainers (bug-hurd@gnu.org) hurd GNU Hurd Maintainers (bug-hurd@gnu.org) mig Marcus Brinkmann ([EMAIL PROTECTED])inetutils Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: Finishing the FHS transition
On Sun, May 06, 2001 at 09:27:59PM +0200, Adrian Bunk wrote: Policy says: -- snip -- In the source package's `Standards-Version' control field, you must specify the most recent version number of this policy document with which your package complies. The current version number is 3.5.4.0. This information may be used to file bug reports automatically if your package becomes too much out of date. -- snip -- Ok, please ignore my other mail. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: Finishing the FHS transition
On 06-May-01, 14:27 (CDT), Adrian Bunk [EMAIL PROTECTED] wrote: Policy says: -- snip -- In the source package's `Standards-Version' control field, you must specify the most recent version number of this policy document with which your package complies. The current version number is 3.5.4.0. This information may be used to file bug reports automatically if your package becomes too much out of date. -- snip -- Uhh, when did that become a must? In 3.5.2 the first paragraph says You should specify the most recent version of the packaging standards with which your package complies in the source package's `Standards-Version' field. Even in 3.5.4, towards the end of that section it says You should regularly, and especially if your package has become out of date, check for the newest Policy Manual available and update your package, if necessary. When your package complies with the new standards you should update the Standards-Version source package field and release it. It says nothing about uploading just to notify that you are still compliant. Hmmm, I don't remember a proposal to change this; I suspect the must slipped in during the recent rewrites, and as Chris Waters pointed out, it is certainly inconsistent with the intent of the field according to recent discussion. you must specify the most recent version number of this policy document with which your package complies: You must upgrade this field when your package complies with a more recent policy - and when your package does already comply with a more recent policy nothing more than an upload with an updated Standards-Version field is needed. Nonsense. I'm not going to upload new versions of packages simply to change that field. Lot's of policy updates have zero effect on most packages, and I doubt many of our users want to spend the time and money downloading and installing a new version of a package to confirm that. I would strongly object if (for example) Branden suddenly started uploading new versions of the X packages every time a new version of policy was released. I'll wait a few days for one of the policy editors to say Oops, that was an accident; if that's not the case, I need to propose an ammendent that clarifies reality, so that Adrian doesn't get mislead again :-). 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: Finishing the FHS transition
Chris Waters wrote: - A change in the policy to remove the obsolete /usr/doc symlinks. This is supposed to happen once enough packages make the transition. No, it is supposed to happen one release _after_ a release in which all the packages have made the transition. So sarge at the earliest, not woody. -- see shy jo
Re: Finishing the FHS transition
* Adrian Bunk [EMAIL PROTECTED] [20010506 21:27]: See above: I want to file a RC bug either because a) the package follows a too old policy or For the /usr/doc problem, bugs with severity: normal have already been filed by doogie and joeyh. For these packages, you simply have to change the severity. At the moment, 103 of these bugs are still open (248 bugs were filed originally): Package: acm Maintainer: Enrique Zanardi [EMAIL PROTECTED] 91371 Package acm still has at least one file in /usr/doc 91382 Package acm still has at least one file in /usr/doc Package: authbind Maintainer: Ian Jackson [EMAIL PROTECTED] 91376 Package authbind still has at least one file in /usr/doc 91387 Package authbind still has at least one file in /usr/doc Package: bock Maintainer: Charles Briscoe-Smith [EMAIL PROTECTED] 91396 Package bock still has at least one file in /usr/doc Package: cqcam Maintainer: Daniel Martin [EMAIL PROTECTED] 91415 Package cqcam still has at least one file in /usr/doc Package: cracklib-runtime Maintainer: Jean Pierre LeJacq [EMAIL PROTECTED] 91407 Package cracklib-runtime still has at least one file in /usr/doc Package: cracklib2 Maintainer: Jean Pierre LeJacq [EMAIL PROTECTED] 91414 Package cracklib2 still has at least one file in /usr/doc Package: cracklib2-dev Maintainer: Jean Pierre LeJacq [EMAIL PROTECTED] 91429 Package cracklib2-dev still has at least one file in /usr/doc Package: csound-doc Maintainer: Guenter Geiger [EMAIL PROTECTED] 91433 Package csound-doc still has at least one file in /usr/doc Package: cup Maintainer: Charles Briscoe-Smith [EMAIL PROTECTED] 91422 Package cup still has at least one file in /usr/doc Package: doc-debian-fr Maintainer: Christophe Le Bars [EMAIL PROTECTED] 91417 Package doc-debian-fr still has at least one file in /usr/doc Package: dtlk Maintainer: [EMAIL PROTECTED] (James R. Van Zandt) 91438 Package dtlk still has at least one file in /usr/doc Package: dtmfdial Maintainer: [EMAIL PROTECTED] (Stephen J. Carpenter) 91450 Package dtmfdial still has at least one file in /usr/doc Package: dvidvi Maintainer: [EMAIL PROTECTED] (David A. van Leeuwen) 91439 Package dvidvi still has at least one file in /usr/doc Package: emacs20-el Maintainer: Rob Browning [EMAIL PROTECTED] 91554 Package emacs20-el still has at least one file in /usr/doc Package: emacsen-common Maintainer: Rob Browning [EMAIL PROTECTED] 91457 Package emacsen-common still has at least one file in /usr/doc Package: f77reorder Maintainer: Alex Romosan [EMAIL PROTECTED] 91444 Package f77reorder still has at least one file in /usr/doc Package: faqomatic Maintainer: [EMAIL PROTECTED] (Scott K. Ellis) 91465 Package faqomatic still has at least one file in /usr/doc Package: ftape-doc Maintainer: Christian Meder [EMAIL PROTECTED] 91463 Package ftape-doc still has at least one file in /usr/doc Package: ftape-util Maintainer: Christian Meder [EMAIL PROTECTED] 91462 Package ftape-util still has at least one file in /usr/doc Package: gap4-gdat Maintainer: Markus Hetzmannseder [EMAIL PROTECTED] 91470 Package gap4-gdat still has at least one file in /usr/doc Package: gap4-tdat Maintainer: Markus Hetzmannseder [EMAIL PROTECTED] 91469 Package gap4-tdat still has at least one file in /usr/doc Package: gbdk-dev Maintainer: Masato Taruishi [EMAIL PROTECTED] 91472 Package gbdk-dev still has at least one file in /usr/doc Package: gbdk-examples Maintainer: Masato Taruishi [EMAIL PROTECTED] 91471 Package gbdk-examples still has at least one file in /usr/doc Package: gcc-m68k-linux Maintainer: Martin Mitchell [EMAIL PROTECTED] 91476 Package gcc-m68k-linux still has at least one file in /usr/doc Package: gerstensaft Maintainer: Martin Schulze [EMAIL PROTECTED] 91477 Package gerstensaft still has at least one file in /usr/doc Package: glimpse Maintainer: Marco Budde [EMAIL PROTECTED] 91484 Package glimpse still has at least one file in /usr/doc Package: gs-aladdin-manual Maintainer: Marco Pistore [EMAIL PROTECTED] 91486 Package gs-aladdin-manual still has at least one file in /usr/doc Package: gs-aladdin-manual-de Maintainer: Marco Pistore [EMAIL PROTECTED] 91483 Package gs-aladdin-manual-de still has at least one file in /usr/doc Package: gsfonts Maintainer: Torsten Landschoff [EMAIL PROTECTED] 91489 Package gsfonts still has at least one file in /usr/doc Package: gsfonts-other Maintainer: Torsten Landschoff [EMAIL PROTECTED] 91485 Package gsfonts-other still has at least one file in /usr/doc Package: htget Maintainer: Troy Hanson [EMAIL PROTECTED] 91497 Package htget still has at least one file in /usr/doc Package: id-utils Maintainer: Brad Bosch [EMAIL PROTECTED] 91555 Package id-utils still has at least one file in /usr/doc Package: idled Maintainer: John Goerzen [EMAIL PROTECTED] 91513 Package idled still has at least one file in /usr/doc Package: infocom Maintainer: Charles Briscoe-Smith [EMAIL PROTECTED] 91515
Re: Finishing the FHS transition
On Sun, May 06, 2001 at 09:27:59PM +0200, Adrian Bunk wrote: On Sun, 6 May 2001, Chris Waters wrote: Didn't we already have this discussion? The Standards-Version field is not a reliable indication of much of anything. I strongly object Policy says: Policy says doesn't make the packages comply. And you can file all the bugs reports you want, but that doesn't magically fix the packages. And until they're fixed, you can't use them as a reliable indicator of FHS compatibility. QED. We have many packages with old Standards-Versions which actually comply with newer standards and *are* FHS compatible, and we have packages with newer Standards-Versions that are NOT FHS compatible. I think that if you really want to focus on FHS compatibility, you're better off ignoring the Standards-Version issues for now. Its just another can of worms. Picking the minimum Standards-Version for release is something we normally do at freeze time. In the source package's `Standards-Version' control field, you must specify the most recent version number of this policy document with which your package complies. The current version number is 3.5.4.0. You're misinterpreting this. It does not mean that every package must be reuploaded every time policy changes. Most recent should be checked at the time you create the source package, not rechecked daily. Note that the next paragraph mentions filing bug reports if the package becomes too much out of date. If any is too much, why bother to say too much? to removing packages because of what amount to cosmetic issues, and an Where did I say that I want to remove the packages??? I said that I want to send bug reports. RC bugs mean the package must be removed from the next release if it's not fixed. Unless you can guarantee that the bugs will be fixed (i.e., you're volunteering to fix them yourself), you _are_ asking for package to be removed when you file RC bugs. Anyway, I apologize for a reminder I'm sure you don't need. It's just a habit of mine, please forgive me. Bottom line, I think there remains a lot of work checking the subtle and not-so-obvious stuff in the FHS before we can confidently claim FHS compatibility (and even *begin* to work on actual compliance). The easy stuff, as your evidence shows, we're actually quite close on. It's the harder stuff, like /var/lib/games (which Kamion was going to investigate) and the random hard-to-identify files that need to move from /usr/lib to /usr/share that needs the most attention. So, anyway, that's a nice list of packages you made, and I think it's probably very useful -- all those packages should inspected -- I just don't think it's very useful for the purpose you intended. And I think mass filings of RC bugs would be premature at best. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Finishing the FHS transition
On Sun, May 06, 2001 at 06:29:05PM -0400, Joey Hess wrote: Chris Waters wrote: - A change in the policy to remove the obsolete /usr/doc symlinks. This is supposed to happen once enough packages make the transition. No, it is supposed to happen one release _after_ a release in which all the packages have made the transition. So sarge at the earliest, not woody. Right. Even better point. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Finishing the FHS transition
On Sun, May 06, 2001 at 09:27:59PM +0200, Adrian Bunk wrote: Policy says: In the source package's `Standards-Version' control field, you must specify the most recent version number of this policy document with which your package complies. The current version number is 3.5.4.0. This information may be used to file bug reports automatically if your package becomes too much out of date. I'm curious to know why it says this. The Must/Should/May proposal certainly listed it as a should, not a must, and I don't recall going ballistic about this on the lists previously and there's isn't an entry in the changelog that I can see, so I can't imagine there having been an accepted proposal about it. So, quite frankly, policy is completely in the wrong here. Do not file RC bugs about standards-versions, nor rely on them for accurate information. They are indicative *only*. 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) pgpslcJ5b8tlk.pgp Description: PGP signature
