Bug#160248: section 13.3 unnecessarily obscure
Package: debian-policy The intent of the last paragraph in section 13.3 is that you should be able to delete /usr/share/doc safely, but that's not quite what it says. need to install the instructions for building and installing the package, of course! - Files in `/usr/share/doc' should not be referenced by any program, and - the system administrator should be able to delete them without causing - any programs to break. Any files that are referenced by programs but - are also useful as standalone documentation should be installed under + The system administrator should be able to delete files in + `/usr/share/doc' without causing any programs to break. A package + should not directly reference files that it places there. Any + files that are referenced by programs but are also useful as + standalone documentation should be installed under `/usr/share/package/' with symbolic links from `/usr/share/doc/package/'. (For those of you playing along at home, think about what happens when the package is a documentation browser). -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpiwQ7fyg09r.pgp Description: PGP signature
Re: Bug#132767: acknowledged by developer (Reviewing policy bugs)
Manoj Srivastava [EMAIL PROTECTED] writes: Robbe Is Unicode manadatory now? (You somewhat incorrecly used Robbe U+2010, hyphen, in that mail.) Mandatory? mandated by whom? Obviously MIME is mandatory for participation in policy process I infer from your Fix your MUA comment. But you were using characters outside ASCII as well, so one needs tools to turn them from UTF8 gibberish into something readable. And, pray tell, why exactly is it incorrect? One can't use this unicode hyphen and have getopt understand it. You were pasting a commandline that didn't work. Incorrect enough for you? I see a hyphen. Hyphen != Hyphen-Minus although they probably look exactly or nearly exactly alike. -- Robbe signature.ng Description: PGP signature
Re: [RFC] *-rc.d - rc.d-* transition
On Sun, 08 Sep 2002, Chris Waters wrote:
First, I'd like to say that I'm fairly neutral in this debate. None
So am I, actually. I am proposing it because I said at debconf2 that I
would, after the people there got convinced it would be a good thing by
whomever proposed it.
1. Since we'll be adding more programs to update-rc.d, we should have fixed
that in the first place (I replied too late to the guy when I heard
this argument :-) )
That's not an an argument, since it's based on the _conclusion_ that
we should change the name. Indeed, IF we decide to change the name,
The argument that invoke-rc.d is stupid, why not rc.d-invoke was made
before the person knew it was already deployed...
we should probably try to do it sooner rather than later for this
reason, but that begs the question: should we try to change the name?
Ideed. Should we? I am certainly not touching invoke-rc.d and policy-rc.d
if update-rc.d is not going to change.
3. Clean namespace and proper grouping of related utilities. rc.d-{update,
invoke, policy}, especially when the upcoming (when they're ready)
init.d-* scripts (for parallel execution and dependency processing in
init scripts) are taken into account.
I don't understand why rc.d-* is any cleaner of a namespace than
*-rc.d. I think this argument is mere noise.
Something about it making the group obvious, I think. There was also
something about verb-noun and noun-verb groupings and common usage, but I
don't recall that one well :-(
but then i haven't seen any strong reasons to make the change.
Nor did I. And I still am not really hot on it, either, as you can see.
The first reason for not making the change is that it is currently
consistent with other, similar update-foo utilities. Changing it
Now, that is a good reason not to change it. Unfortunately, the fact that
now we have a bunch of *-rc.d and will have a bunch of init.d-* utilities
could be used to make the same argument.
Against these weak reasons we have, what? The idea that a .d suffix
should indicate a directory? Well, most directories do NOT have a
That one is pretty weak alright :-)
--
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
Re: [RFC] *-rc.d - rc.d-* transition
On Sun, Sep 08, 2002 at 07:20:31PM -0400, Joey Hess wrote: I dislike the rc.d anywhere in the name on general aestetic principles, but Chris's arguments about the update- prefix are persuasive to me. I'd much rather see the rc.d name dropped where possible for init, so we'd have invoke-init, update-init and so on. I second this. Moreover, I think it's a good idea because we want to standardize around one set of tools for Debian packages (and even users) to invoke when they need to interact with the init system in this fashion, and we shouldn't really care about whether the underlying init system uses file rcs or rc directories or whatever. If we think ahead just a little, then we won't have scripts named a certain way for historical reasons which may not apply when someone has swapped out System V init for something else, perhaps based on a very different technology. The important thing is the functionality. I'm neutral on the issue of whether the verb or noun should come first. * On the one hand, having the noun first nicely groups related system functions together, and may be more helpful to people using tab completion. * On the other hand, there's a fair about of Debian inertia in the other direction. update-this, update-that, update-foo, update-bar. I myself have contributed to his inertia, unfortunately. (update-fonts-alias et al.) I prefer the former, but if people are going to have a hissy fit about it, then I can abandon that. My preference for update-init over update-rc.d is much greater than my preference for init-update over update-init. -- G. Branden Robinson|To Republicans, limited government Debian GNU/Linux |means not assisting people they [EMAIL PROTECTED] |would sooner see shoveled into mass http://people.debian.org/~branden/ |graves. -- Kenneth R. Kahn pgpVPRNm6yp67.pgp Description: PGP signature
Bug#160248: section 13.3 unnecessarily obscure
On Mon, Sep 09, 2002 at 07:20:14PM +0100, Andrew Suffield wrote: + The system administrator should be able to delete files in + `/usr/share/doc' without causing any programs to break. A package + should not directly reference files that it places there. Sure it should: ``further documentation may be found in /usr/share/doc/foo''. Better would probably be to say A package should not require the existance of any files in /usr/share/doc to run. Which is pretty much repeating yourself, if that matters. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.''
