Re: [RFC] *-rc.d - rc.d-* transition
Chris Waters wrote:
I think there is one argument against the proposal which has been
completely overlooked: update-rc.d is consistent with other similar
debian utilities like update-menus and update-alternatives. This is
not a strong argument, but I don't see any strong arguments on either
side.
I concur, but would like to promote the above argument to a strong
argument in favour of keeping the {/sbin,/usr/sbin}/update-*
consistency.
=
$ ls -1 /sbin/update-* /usr/sbin/update-*
/sbin/update-grub
/sbin/update-modules
/usr/sbin/update-alternatives
/usr/sbin/update-catalog
/usr/sbin/update-fmtutil
/usr/sbin/update-fonts-alias
/usr/sbin/update-fonts-dir
/usr/sbin/update-fonts-scale
/usr/sbin/update-gtk-immodules
/usr/sbin/update-inetd
/usr/sbin/update-ispell-dictionary
/usr/sbin/update-mime
/usr/sbin/update-mozilla-chrome
/usr/sbin/update-ms-fonts
/usr/sbin/update-pango-modules
/usr/sbin/update-pangox-aliases
/usr/sbin/update-passwd
/usr/sbin/update-rc.d
/usr/sbin/update-texmf
/usr/sbin/update-usb.usermap
/usr/sbin/update-vfontcap
/usr/sbin/update-xpdfrc
$ ls -1 /sbin/*-update /usr/sbin/*-update
ls: /sbin/*-update: No such file or directory
ls: /usr/sbin/*-update: No such file or directory
=
The {/sbin,/usr/sbin}/update-* convention is widely used and so
consistently applied as to be easy to remember. As an admin, if I want
to find the Debian tool to update some configuration information,
there's an overwhelming chance it's named using this convention.
This argument seems stronger than any argument so far in favour of
/usr/sbin/rc.d-update and friends.
[Henrique de Moraes Holschuh wrote:]
5. there is no real reason not to do the change in the first place,
users are NOT supposed to be using rc.d-update directly anyway
The same could be said of update-mime, update-fonts-alias, etc. But
it's not true. There are two reasons. Neither are strong reasons,
but then i haven't seen any strong reasons to make the change.
It's certainly not true that users are not supposed to be using (the
update tools) directly. The convenience of these tools makes them an
ideal solution for problems like How do I change the default
configuration of foo?, and in my experience /usr/sbin/update-rc.d is a
prime example of a tool well-matched for a common problem.
Thus the users are not supposed to be using them directly is at best
open to debate. They *are* used directly, and I don't see any reason
why they should not be. Thus, they are a convenient tool, and their
current consistent naming makes them easy to use.
The above argument may not meet Chris's criteria for strong, but I
believe it's stronger than any of the arguments presented in favour of
changing the name of these tools -- most of which were rightly
classified by Chris as weak.
--
\ Smoking cures weight problems. Eventually. -- Steven Wright |
`\ |
_o__) |
[EMAIL PROTECTED] F'print 9CFE12B0 791A4267 887F520C B7AC2E51 BD41714B
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 confess that I like update-init better myself, but I have to ask:
is the transition worth it? I have a fairly modest installation here
(recently rebuilt after a HD crash), and I see this:
~ $ grep update-rc.d /var/lib/dpkg/info/*{pre,post}{inst,rm}|wc -l
88
Which suggests that there's somewhere between 20 and 44 packages using
update-rc.d right now. Enough to justify a transition plan at the
very least. Enough that I'm questioning (though not formally
objecting to) this change.
--
Chris Waters | Pneumonoultra-osis is too long
[EMAIL PROTECTED] | microscopicsilico-to fit into a single
or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: [RFC] *-rc.d - rc.d-* transition
On Tue, 10 Sep 2002, Chris Waters wrote:
~ $ grep update-rc.d /var/lib/dpkg/info/*{pre,post}{inst,rm}|wc -l
88
If you use update-rc.d, you will call init scripts with 99.9% probability.
That means you _will have to_ switch to invoke-rc.d (sooner or later
anyway). For people using debhelper, both means just a recompile. For
others, it means the package has to be changed anyway.
So we should decide if there is a good reason to change the namings NOW. I
am ok with the idea that we just keep them, but not because of touching too
many packages. Most of those will have to be touched for invoke-rc.d
anyway.
--
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, 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
Re: [RFC] *-rc.d - rc.d-* transition
First, I'd like to say that I'm fairly neutral in this debate. None
of my packages will be affected either way, and I have no strong
feelings about the namespaces involved. Nevertheless, I think there
is one argument against the proposal which has been completely
overlooked: update-rc.d is consistent with other similar debian
utilities like update-menus and update-alternatives. This is not a
strong argument, but I don't see any strong arguments on either side.
On Sun, Sep 08, 2002 at 01:48:35PM -0300, Henrique de Moraes Holschuh wrote:
The arguments for the transition were, as far as I recall:
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,
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?
2. Far easier stem-searching while working with the stuff (rc.dtab),
makes far more sense, too.
That might make sense if this were something that people used
directly, but, as argued in point 5, people generally don't. In any
case, this argument is more applicable to update-menus or
update-modules or update-inetd. If this is really a valid argument,
then you should be trying to get all of those changed as well.
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.
4. update-rc.d should have been called rc.d-update in the first place
Another example, like point 1, of taking your conclusion and calling
it an argument. -2 points for circular reasoning and begging the question.
5. there is no real reason not to do the change in the first place, users
are NOT supposed to be using rc.d-update directly anyway
The same could be said of update-mime, update-fonts-alias, etc. But
it's not true. There are two reasons. Neither are strong reasons,
but then i haven't seen any strong reasons to make the change.
The first reason for not making the change is that it is currently
consistent with other, similar update-foo utilities. Changing it
may make it harder for DDs to find if they search the update-*
namespace (which is what I usually do in similar cases). The second
reason is also about consistency: during the transition, there will be
some packages using update-rc.d and some using rc.d-update, which may
confuse people studying our packages. Not strong reasons, but reasons
nonetheless.
Against these weak reasons we have, what? The idea that a .d suffix
should indicate a directory? Well, most directories do NOT have a
.d suffix. And it's pretty obvious to anyone who looks that
update-rc.d is not a directory. The fact that it doesn't have the
directory bit set, the fact that you can't cd into it, the fact that
it's located in /usr/sbin, and the fact that file(1) calls it a perl
script: all of these are big clues that you're not dealing with a
directory here.
Without any strong reasons on either side of the debate, I'm inclined
to vote for the status quo.
--
Chris Waters | Pneumonoultra-osis is too long
[EMAIL PROTECTED] | microscopicsilico-to fit into a single
or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: [RFC] *-rc.d - rc.d-* transition
Henrique de Moraes Holschuh wrote: I am not sure. Maybe Joey Hess, or one of the others kept some. Nope. Does anyone have a debconf transcript? What happened to those video tapes? I wanted to review some of the discussion during my debconf talk too. 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. -- see shy jo pgp5NcLMGlqGR.pgp Description: PGP signature
Re: [RFC] *-rc.d - rc.d-* transition
On Sun, Sep 08, 2002 at 11:58:31AM -0700, Chris Waters wrote: The second reason is also about consistency: during the transition, there will be some packages using update-rc.d and some using rc.d-update, which may confuse people studying our packages. Not strong reasons, but reasons nonetheless. It also breaks partial upgrades once the transition is complete: upgrading sysvinit to an rc.d-update only version will mean you're no longer able to upgrade old packages to anything but rc.d-update compliant versions. If one of those packages happen to have become unmaintained in the meantime, you're a bit screwed. There's no way of avoiding this, since update-rc.d is considered essential and no one depends on it. You could do a tedious usr/share/doc-style transition over two or three releases, but there just isn't any point to all this. How pretty names are isn't *that* important. If they were, we'd've changed /etc to /conf and so on years ago. 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.'' pgpnIOcIYPTmV.pgp Description: PGP signature
Re: [RFC] *-rc.d - rc.d-* transition
In article [EMAIL PROTECTED], Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: As it was talked in Debconf2, we would be better off if we renamed all *-rc.d utilities (invoke-rc.d, policy-rc.d, update-rc.d) to rc.d-* (rc.d-invoke, rc.d-policy, rc.d-update). Is there documentation online about that? Mike.
Re: [RFC] *-rc.d - rc.d-* transition
On Fri, Sep 06, 2002 at 06:50:03PM -0300, Henrique de Moraes Holschuh wrote: As it was talked in Debconf2, we would be better off if we renamed all *-rc.d utilities (invoke-rc.d, policy-rc.d, update-rc.d) to rc.d-* (rc.d-invoke, rc.d-policy, rc.d-update). Uh, that seems entirely gratuitous. 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.'' pgphy9BNwBVa2.pgp Description: PGP signature
Re: [RFC] *-rc.d - rc.d-* transition
* Anthony Towns (aj@azure.humbug.org.au) [020907 13:11]: On Fri, Sep 06, 2002 at 06:50:03PM -0300, Henrique de Moraes Holschuh wrote: As it was talked in Debconf2, we would be better off if we renamed all *-rc.d utilities (invoke-rc.d, policy-rc.d, update-rc.d) to rc.d-* (rc.d-invoke, rc.d-policy, rc.d-update). Uh, that seems entirely gratuitous. I can not parse your comment. I think it is the right thing to do, since it removes the .d from the end of the file, which indicates a directory, normally. So we would avoid missconceptions.
Re: [RFC] *-rc.d - rc.d-* transition
On Sep 07, Andreas Schuldei wrote: Uh, that seems entirely gratuitous. I can not parse your comment. dict gratuitous, then it should make sense :-) IMO it would be more worthwhile to do this in conjunction with adding extra functionality/package requirements (i.e. better/more abstract init script message handling, additional required init.d functionality like status, etc.), so while people are fiddling with their init handling anyway to do this they can also upgrade the functionality. Not that I'm personally proposing these things, but I know there are people that need/want them. I'd also suggest a transition point where the old names invoke the new routines, but with a warning to standard error, so people can catch these problems before they break packages; in fact, it might be best to keep the legacy names around with warnings for a while (i.e. past at least sarge+1, and maybe even indefinitely). Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/
Re: [RFC] *-rc.d - rc.d-* transition
On Sat, Sep 07, 2002 at 01:14:17PM +0200, Andreas Schuldei wrote: * Anthony Towns (aj@azure.humbug.org.au) [020907 13:11]: On Fri, Sep 06, 2002 at 06:50:03PM -0300, Henrique de Moraes Holschuh wrote: As it was talked in Debconf2, we would be better off if we renamed all *-rc.d utilities (invoke-rc.d, policy-rc.d, update-rc.d) to rc.d-* (rc.d-invoke, rc.d-policy, rc.d-update). Uh, that seems entirely gratuitous. I can not parse your comment. It's a waste of time, for no technical benefit. If we have to change the name anyway, then choosing a better name is worthwhile, but we don't need to change the name, so we shouldn't go around deprecating every single script that manages init.d scripts, and confusing all the developers and admins who've already taken the time to learn how update-rc.d works. 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.'' pgp44asywSFKP.pgp Description: PGP signature
Re: [RFC] *-rc.d - rc.d-* transition
Andreas Schuldei [EMAIL PROTECTED] wrote:
I think it is the right thing to do, since it removes the .d from
the end of the file, which indicates a directory, normally. So we
would avoid missconceptions.
If that's the only reason then this is totally pointless.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[RFC] *-rc.d - rc.d-* transition
As it was talked in Debconf2, we would be better off if we renamed all *-rc.d utilities (invoke-rc.d, policy-rc.d, update-rc.d) to rc.d-* (rc.d-invoke, rc.d-policy, rc.d-update). Transition plan: 1a. Rename all scripts to their new names, add compatibility symlinks to the sysvinit and file-rc packages. The scripts can be executed by both names. 1b. Change policy to recommend the new names, and deprecate the old ones. Email debian-devel-announce about it, so that other docs get updated (as if...). 2. Change debhelper (and any other maintainer script templates) to use the new format. 3. File wishlist bugs to all non-debhelper-using packages to switch to the new naming scheme. 4. wait for sarge to be released 5. Change policy to forbid the old naming. File bugs, NMU all packages still using the old ones. 6. wait for sarge+1 to be released 7. remove the compatibility symlinks. If there are no problems with this transition plan, I will write a policy proposal shortly. -- 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
Hi, Sounds right to me. manoj -- Remember, extremism in the nondefense of moderation is not a virtue. Peter Neumann, about usenet 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
