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?
Bug#91257: re-proposing this
On Sun, May 06, 2001 at 10:55:14AM -0500, Branden Robinson wrote: On Sun, May 06, 2001 at 01:45:28AM -0500, Sam TH wrote: Why should packages that require a particular font package for operation (and indeed normally require that package to be installed on the local system AND the remote system) not depend on their font packages? Why did you not read the footnote that IMMEDIATELY followed the text you quoted? Why did you not read the text you just quoted? I've never seen AbiWord work over remote X if the fonts weren't installed in *both* locations. Thus, AbiWord installs on a machine without the fonts are *not useful* *at all*. sam th --- [EMAIL PROTECTED] --- http://www.abisource.com/~sam/ OpenPGP Key: CABD33FC --- http://samth.dyndns.org/key DeCSS: http://samth.dynds.org/decss pgpKrPaXz3Bhn.pgp Description: PGP signature
Bug#96629: 3.2 and 2.3 package naming not synchronized
Package: debian-policy Version: 3.5.2.0 Severity: normal Currently, sections 3.2.1 and 2.3.1 both give rules for package naming. The latter is, however, more strict, and both use different terminology. I suggest these two get synchronized and both be evenly strict. I checked the version on the website and on CVS (not on my machine). -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux catv6142 2.2.18 #1 Fri Dec 15 12:11:13 CET 2000 i686 Versions of packages debian-policy depends on: ii fileutils 4.0.43-1 GNU file management utilities.
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
Bug#91257: re-proposing this
* Sam TH [EMAIL PROTECTED] [010507 00:11]: I've never seen AbiWord work over remote X if the fonts weren't installed in *both* locations. Thus, AbiWord installs on a machine without the fonts are *not useful* *at all*. Sam, please don't take offense at this: the way I see it, if program cannot function normally under circumstances that most X clients won't even notice, I tend to think program is broken. Taking Branden's proposal entirely in the abstract, it is simply codifying the way X was designed to run. Anything against this *is* a bug, because it is not keeping with the network transparency of X. However, if the AbiWord developers don't figure they will get around to fixing AbiWord any time soon, it sure would be a shame to keep AbiWord out of the distribution. Branden, would you have great compunction against making your current must a should? -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Re: Tasks policy
On Sun, May 06, 2001 at 04:42:19PM +1000, Anthony Towns wrote: (Cc'ed to debian-boot) (First in porbably a series of policy changes needed for woody...) So, here's the deal. We need to get a proper policy for tasks fairly soon. tasksel in sid supports a Task: header for packages so we can be a little more flexible than having every task- depend on everythig in it. Can I make a suggestion? This sounds really good in general, but the one headache you've identified is the necessity to set up the Task fields in lots of packages and the consequent maintenance of this data. Would it not be much easier for the task packages _themselves_ to contain Task: fields, instead of the individual packages, which would function like weak Recommends: fields: they select the packages for installation if present when first installed, but don't try reselecting them if they are unselected or later uninstalled. (Maybe there could be some sort of reinstall facility, though, in apt/dselect.) In this way, the dependency information remains in the domain of the task-* package maintainers, but has the desired function. 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: Bug#91257: re-proposing this
On Sun, May 06, 2001 at 04:47:07PM +1000, Anthony Towns wrote: (Later being after we work out a satisfactory way of specifying what must is meant to specify. Julian, I'd really appreciate it if you could propose something along those lines. But not in this thread...) My current order of priorities: (1) Finish entering my textual improvements into CVS (2) Make some progress on cleaning up the Policy bugs list (which is ever growing) In the meantime, I think Manoj is planning to convert policy to Docbook XML format. (3) Rewrite policy so that it's more comprehensible: its ordering (merger of policy + packaging) is really hard work. When I'm doing (3), I will make the changes to MUST and SHOULD which I've suggested, and will present it to this list for ratification. If the whole shebang is approved, then it can go in. But I don't want to put in the effort to make the changes at this point. 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: Tasks policy
On Mon, May 07, 2001 at 11:06:41AM +0100, Julian Gilbey wrote: On Sun, May 06, 2001 at 04:42:19PM +1000, Anthony Towns wrote: (Cc'ed to debian-boot) tasksel in sid supports a Task: header for packages so we can be a little more flexible than having every task- depend on everythig in it. Can I make a suggestion? This sounds really good in general, but the one headache you've identified is the necessity to set up the Task fields in lots of packages and the consequent maintenance of this data. I'm thinking it'll probably be best if a list of which packages are in which tasks is maintained as part of boot-floppies CVS, and that dak/dinstall updates the Task: fields based on that. Would it not be much easier for the task packages _themselves_ to contain Task: fields, instead of the individual packages, which would function like weak Recommends: fields: Not really. The code's already written to do things the other way around, and the main point of Task: fields being in the package is so that packages can be removed from the archive without breaking any tasks they might be a part of. In this way, the dependency information remains in the domain of the task-* package maintainers, but has the desired function. It'd be possible to do this, too (either informally by saying only task package maintainers should mess with this part of CVS or by making dak/dinstall look at the actual contents of the latest task- packages). I suspect using CVS'll be easier and at least as good though. 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) pgpVfeNHCReI9.pgp Description: PGP signature
Must/should/may
On Mon, May 07, 2001 at 11:14:36AM +0100, Julian Gilbey wrote: (3) Rewrite policy so that it's more comprehensible: its ordering (merger of policy + packaging) is really hard work. When I'm doing (3), I will make the changes to MUST and SHOULD which I've suggested, and will present it to this list for ratification. If the whole shebang is approved, then it can go in. But I don't want to put in the effort to make the changes at this point. Honestly, I think any changes to Must/Should/May need more discussion. I'm becoming increasingly wary of leaving it in policy.sgml: there's already two instances of shoulds becoming musts without any formal proposal or a by your leave or anything. That's *completely* wrong and distracting, and shouldn't *ever* happen. I can't see any reason not to expect it to keep happening though with what you've proposed: adding or losing a (*) seems at least as easy as sneakily changing a must to a should or vice-versa. One way of avoiding that would be to put the RC policy issues into a separate Release goals document, and not having the policy editors make even typographical changes to that without an appropriately seconded amendment. A separate document would probably be quite convenient, imo. But it'd be hard to keep in sync with policy itself, without ending up repeating policy. Is there any way to do cross document links, so you can say something like (1) Packages must include copyright and changelogs (see a href=policy#copyrightchangelog) and have it be nicely typeset? 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)
Bug#91257: re-proposing this
On Mon, May 07, 2001 at 03:08:38AM -0700, Seth Arnold wrote: * Sam TH [EMAIL PROTECTED] [010507 00:11]: I've never seen AbiWord work over remote X if the fonts weren't installed in *both* locations. Thus, AbiWord installs on a machine without the fonts are *not useful* *at all*. Sam, please don't take offense at this: the way I see it, if program cannot function normally under circumstances that most X clients won't even notice, I tend to think program is broken. Well, it certainly would be nice to be able to fix this. But no one has come up with a good solution yet. Taking Branden's proposal entirely in the abstract, it is simply codifying the way X was designed to run. Anything against this *is* a bug, because it is not keeping with the network transparency of X. Unfortunately, X fonts aren't as nicely transparent as X apps. And since AbiWord needs to be able to guarantee the availability of certain fonts, this means those fonts need to be installed in a place AbiWord can find them. If we could expect that a decent set of printable fonts were shipped with all X installations, we wouldn't have that problem. But good luck getting that. However, if the AbiWord developers don't figure they will get around to fixing AbiWord any time soon, it sure would be a shame to keep AbiWord out of the distribution. Branden, would you have great compunction against making your current must a should? We'd love to fix AbiWord. But no one has come up with a good solution yet. (Actually, I think people have gotten both the fonts and the app to be served remotely, but that still requires that the fonts be installed on the same system.) sam th --- [EMAIL PROTECTED] --- http://www.abisource.com/~sam/ OpenPGP Key: CABD33FC --- http://samth.dyndns.org/key DeCSS: http://samth.dynds.org/decss pgpUkT4kKs1OT.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: Must/should/may
On Mon, May 07, 2001 at 08:51:00PM +1000, Anthony Towns wrote: On Mon, May 07, 2001 at 11:14:36AM +0100, Julian Gilbey wrote: (3) Rewrite policy so that it's more comprehensible: its ordering (merger of policy + packaging) is really hard work. When I'm doing (3), I will make the changes to MUST and SHOULD which I've suggested, and will present it to this list for ratification. If the whole shebang is approved, then it can go in. But I don't want to put in the effort to make the changes at this point. Honestly, I think any changes to Must/Should/May need more discussion. I'm becoming increasingly wary of leaving it in policy.sgml: there's already two instances of shoulds becoming musts without any formal proposal or a by your leave or anything. That's *completely* wrong and distracting, and shouldn't *ever* happen. I can't see any reason not to expect it to keep happening though with what you've proposed: adding or losing a (*) seems at least as easy as sneakily changing a must to a should or vice-versa. Agreed. It seems like something went very wrong somewhere. But only once. I intend to fix up the mess when doing (3). Actually, my (practical) suggestion makes it harder to actually introduce changes than before: I have suggested using entities, which would require intentionally changing an entity to change the meaning. I think that without experimentation of the new system, it's way to early to suggest this. One way of avoiding that would be to put the RC policy issues into a separate Release goals document, and not having the policy editors make even typographical changes to that without an appropriately seconded amendment. Gosh. What a radical idea. (I'm sure I suggested something very similar to this a while ago.) A separate document would probably be quite convenient, imo. But it'd be hard to keep in sync with policy itself, without ending up repeating policy. Is there any way to do cross document links, so you can say something like (1) Packages must include copyright and changelogs (see a href=policy#copyrightchangelog) and have it be nicely typeset? Should be doable. I don't yet know the details, though. And I'm not going to figure out anything until I get to (3). 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: Tasks policy
err, does this break the use of tasks with apt-get later on? I've found it very useful to do (for example) apt-get install task-x-window-system after getting a machine otherwise working (in particular, that's the easy way to go to xf4 - install 2.2, then point to testing, then apt-get install task-x-window-system which pulls in the right things from testing...) Does it not also make it a lot harder to update and experiment with tasks? (Couldn't this also be handled by dropping non-critical task deps to recommends or something like that, and an apt-get option to try to get the recommends too?)
Bug#91257: re-proposing this
Please pay attention to my Mail-Copies-To and X-No-CC headers this time. On Mon, May 07, 2001 at 02:20:54AM -0500, Sam TH wrote: Why did you not read the text you just quoted? I've never seen AbiWord work over remote X if the fonts weren't installed in *both* locations. Sounds like a bug in AbiWord. And perhaps you missed this part: + For the purposes of Debian Policy, a font for the X Window + System is one which is accessed via X protocol requests. + Fonts for the Linux console, for PostScript renderers, or + any other purpose, do not fit this definition. Any tool + which makes such fonts available to the X Window System, + however, must abide by this font policy. -- G. Branden Robinson | Men use thought only to justify their Debian GNU/Linux| wrong doings, and speech only to conceal [EMAIL PROTECTED] | their thoughts. http://www.debian.org/~branden/ | -- Voltaire pgpgtAkuJ0n3K.pgp Description: PGP signature
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: Tasks policy
On Mon, May 07, 2001 at 11:42:49AM -0400, Mark Eichin wrote: err, does this break the use of tasks with apt-get later on? I've found it very useful to do (for example) apt-get install task-x-window-system Possibly. task-x-window-system isn't really the greatest example of a task, though. You can always run tasksel, select the task, and go Ok, instead of using apt-get install ... though. Making tasksel install server-dns just go ahead and install the task, bypassing the UI, would be fairly simple too. Does it not also make it a lot harder to update and experiment with tasks? Not really: the Task: headers will be done via overrides, probably sourced from boot-floppies CVS. (Couldn't this also be handled by dropping non-critical task deps to recommends or something like that, and an apt-get option to try to get the recommends too?) In theory it could. In practice, it suffers from recommends being more appropriately handled in a frontend rather than a lowlevel tool like apt-get (to paraphrase, barely, Jason's take on apt-get supporting recommends), and also from the same problems using depends: does: if I remove a package from the task, the whole task breaks, rather than just politely including one less package. This was discussed in a fair degree of depth shortly after potato was released, btw. Have a look at the thread on -devel which included: http://lists.debian.org/debian-devel-0008/msg00706.html 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) pgpMAYJLK98Ul.pgp Description: PGP signature
Re: Tasks policy
On Mon, May 07, 2001 at 11:42:49AM -0400, Mark Eichin wrote: err, does this break the use of tasks with apt-get later on? I've found it very useful to do (for example) apt-get install task-x-window-system after getting a machine otherwise working (in particular, that's the easy way to go to xf4 - install 2.2, then point to testing, then apt-get install task-x-window-system which pulls in the right things from testing...) My thought was that apt and dselect would be taught to recognise Tasks: as a new type of dependency header, similar to Depends, Recommends and Suggests, but with slightly different rules. 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: Tasks policy
On Sun, 06 May 2001, Anthony Towns wrote: So, here's the deal. We need to get a proper policy for tasks fairly soon. I agree. The current task-* packages are mostly useless cruft for what they were supposed to do, i.e. help users during the install. * There should only be a limited number of tasks This is very, very important. I think about 30 is the maximum number of tasks we should have. If people would like to indicate their willingness to second this, I'd be happy to write up a proper patch. Please do, I think this changes are very necessary and I am willing to discuss and second a proposal about it. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgpfJZHtjeHOH.pgp Description: PGP signature
Re: Tasks policy
Julian Gilbey wrote: On Mon, May 07, 2001 at 11:42:49AM -0400, Mark Eichin wrote: err, does this break the use of tasks with apt-get later on? I've found it very useful to do (for example) apt-get install task-x-window-system after getting a machine otherwise working (in particular, that's the easy way to go to xf4 - install 2.2, then point to testing, then apt-get install task-x-window-system which pulls in the right things from testing...) My thought was that apt and dselect would be taught to recognise Tasks: as a new type of dependency header, similar to Depends, Recommends and Suggests, but with slightly different rules. If this were done, I would much prefer it were called Reverse-Recommends, since such a thing is useful for other purposes too. I was thinking that the relationship created by a Task: field is a reverse dependancy, but that is not true, it is not as hard a relation as a dependancy since it can be overridden in many ways (the simplest being, get a Packages file that does not include the package with the Task: field). Instead, it's like a recommends. And while we're at it, we could implement Reverse-Suggests too, and finally satisfy RMS.. -- see shy jo
Special init.d scripts
Most init.d scripts are expected to support all of start, stop, etc. options. But there are a small number of scripts which are obvious exceptions to this rule: restart, reboot, single, mountall.sh and so on. It would be really nice to have a paragraph in policy distinguishing between these cases and the rest of them, but I've no idea what it should say. Does anyone have any ideas? 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/
Bug#66023: PROPOSAL] Re: Shared libs vs. plugins.
On Sun, May 06, 2001 at 11:58:56PM +0300, Richard Braakman wrote: Yes, but if I amend the proposal like this, then it needs to be seconded all over again, doesn't it? I don't see why. You need two seconds to go from proposal to amendment. To go from amendment to accepted, you need consensus on the mailing list. This consensus presumably includes the opinions of the original seconders. Achieving consensus is usually going to involve some minor changes to the amendment -- that's the whole point of discussing it. If those changes then invalidate the amendment so that the whole process has to be started over again, then the policy process would be quite heavyweight. I don't think that was the intent. Well, they don't invalidate it, but they change it from the one that the seconders seconded. How do I know their second still stands for the changed proposal, unless I get them to second it again? (It most probably does in this case.) -- Digital Electronic Being Intended for Assassination and Nullification
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: Special init.d scripts
On 07-May-2001 Julian Gilbey wrote: Most init.d scripts are expected to support all of start, stop, etc. options. But there are a small number of scripts which are obvious exceptions to this rule: restart, reboot, single, mountall.sh and so on. It would be really nice to have a paragraph in policy distinguishing between these cases and the rest of them, but I've no idea what it should say. Does anyone have any ideas? perhaps a naming convention would be nice too. For instance most of the .sh scripts are not typical scripts.
Re: Tasks policy
Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony --HG+GLK89HZ1zG0kk Content-Type: text/plain; Anthony charset=us-ascii Content-Disposition: inline Anthony Content-Transfer-Encoding: quoted-printable Anthony On Mon, May 07, 2001 at 11:42:49AM -0400, Mark Eichin Anthony wrote: err, does this break the use of tasks with apt-get later on? I've found it very useful to do (for example) apt-get install task-x-window-s= Anthony ystem Anthony Possibly. task-x-window-system isn't really the greatest Anthony example of a task, though. So, I think that support in tools besides tasksel is critical to this policy proposal being useful. I don't like the idea of having frontend-specific fields being mandated by policy and don'tt see a need for tasksel to be a distinguished frontend. I understand why apt-get might not want to support or reverse-recommends, but I think that the actual frontends should support this.
Re: Special init.d scripts
* Julian Gilbey [EMAIL PROTECTED] [010507 15:44]: Most init.d scripts are expected to support all of start, stop, etc. options. But there are a small number of scripts which are obvious exceptions to this rule: restart, reboot, single, mountall.sh and so on. Julian, I'm inclined to think that unless someone is complaining about these scripts, we may as well leave well enough alone. :) -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Re: Tasks policy
On Mon, May 07, 2001 at 04:23:47PM -0400, Joey Hess wrote: My thought was that apt and dselect would be taught to recognise Tasks: as a new type of dependency header, similar to Depends, Recommends and Suggests, but with slightly different rules. If this were done, I would much prefer it were called Reverse-Recommends, since such a thing is useful for other purposes too. I was thinking that the relationship created by a Task: field is a reverse dependancy, but that is not true, it is not as hard a relation as a dependancy since it can be overridden in many ways (the simplest being, get a Packages file that does not include the package with the Task: field). Instead, it's like a recommends. Gosh, that's not quite what I meant, but it could be an interesting idea. I was still thinking in terms of the task-* packages themselves containing a Tasks: field in place of Depends and Recommends fields. And while we're at it, we could implement Reverse-Suggests too, and finally satisfy RMS.. What about Enhances? Or is it not yet up to it? 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/
CVS jdg: * Done chapter 10 now
CVSROOT:/cvs/debian-policy Module name:debian-policy Changes by: jdg Mon May 7 17:21:13 PDT 2001 Modified files: . : policy.sgml debian : control Removed files: DebianDoc_SGML/Format: Text.pm Log message: * Done chapter 10 now * debiandoc-sgml version 1.1.47 fixes most of the issues, so Text.pm can be removed again * Versioned build-depends for this * Merged changes to LaTeX.pm
Bug#66023: PROPOSAL] Re: Shared libs vs. plugins.
On Mon, May 07, 2001 at 10:58:19PM +0200, Josip Rodin wrote: Yes, but if I amend the proposal like this, then it needs to be seconded all over again, doesn't it? [...] Well, they don't invalidate it, but they change it from the one that the seconders seconded. How do I know their second still stands for the changed proposal, unless I get them to second it again? (It most probably does in this case.) Seconders have to be expected to keep paying attention to the things they second. If the proposal becomes amended in such a way that they disagree with it, they have to speak up. If they can't be bothered to pay that much attention, they should either not second it in the first, or be prepared to accept that they might lend their support to proposals with which they disagree. Remember, policy is supposed to be a lightweight process. -- G. Branden Robinson | Optimists believe we live in the best of Debian GNU/Linux| all possible worlds. Pessimists are [EMAIL PROTECTED] | afraid the optimists are right. http://www.debian.org/~branden/ | pgpFSyOZokLmP.pgp Description: PGP signature
