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.d<tab>),
> 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
xtifr@debian.org | microscopicsilico- to fit into a single
or xtifr@speakeasy.net | volcaniconi- standalone haiku
Reply to: