On Fri, 08 Sep 2006, Petter Reinholdtsen wrote: > [Henrique de Moraes Holschuh] > > Also, may I humbly suggest naming the new package sysvinit-utils instead of > > sysvutils? > > Personally I prefer the sysv prefix, to match sysv-rc. Part of my > rationale is that the killall5, last, lastb, mesg and pidof binaries > don't really have anything to do with the init program or system as > such, they are just useful tools, and I assume they are commonly found > in sysv-based unix systems.
I agree with that, but since there's the caveat that sysv is a prefix of an entire world of stuff and NOT of the initscript subsystem, a sysv-utils package should be available for other ATT SysV utilities, which have nothing to do with init at all. Sort like the mess util-linux has become. Do we really want to open ourselves to a possible multiple-upstream, not initscript-centric package on the future? Or to what happened to the inet* stuff/netkit-* stuff? What we are dealing with is sysvinit, not sysv. Heck, "lp" from cupsys is sysv too, and that's as far away from initscript as we could get :-p sysv-rc is not a prefix, it is explicitly's sysv rc, so naming the package that has it inside "sysv-rc" is not likely to become a problem ever. But killall5, last, lastb, mesg, pidof... those could either belong to a sysv-utils package (that could have other sysv utilities), or to a sysvinit-utils/sysvrc-utils package (that would always be single-source, single-upstream). So let's please place them where it will never cause us trouble: a sysvinit-utils or sysv-rc-utils package. And sincerely, I'd really, really like to drop "rc" sometime in the future, init is two letters away from rc, and unlike rc it has an actual meaning :-) That goes even for our *-rc.d utilities, *if* we ever revise their interfaces in a non-backwards-compatible way (which we might have to do eventually, when the cruft becomes too big). No, this has nothing to do with renaming the sysv-rc package. Sysv-rc is a particular way to implement a sysv-like initscript system :p What really defines sysv-style init scripts is /etc/init.d scripts, and their actions (start, stop...). > But I have no strong opinion if the best name is sysv-utils, > sysvutils, sysv-tools or sysvtools. And because I have no strong > opinion on the name, I choose compatibility with others as the most > important factor, and suggest we use the same name as ubuntu, if we > get the split working. I'd normally go with this, but look at where such non-forward-proof way of doing things got us re. update-rc.d. Someone wrote it waaaay back, before even the first Debian release, gave it absolutely *no* thought whatsoever other than what was strictly needed for fixing the immediate problem... to the point that it is not even able to separate local admin changes to package changes like dpkg-divert does. Just as icing in the cake, update-rc.d was also given a command line interface that is hard to extend in a safe manner. Was it wrong to do it like this? No. Was it the best way it could be done? No. Did it cause trouble to us and our users? *yes* (try to setup udev or util-linux to start/stop where you want them, then upgrade the packages and watch as your local admin decisions get overriden -- and we *cannot* fix this without a new update-rc.d transition!). I'd like to avoid shortsighted naming of tools, packages, and non-safely-designed interfaces for *forward* compatibility as much as possible in the initscript subsystem. Yes, the naming of a package is a very minor thing, but if it is something we *can* get right now, why should we just go on with an imperfect naming that *may* cause problems in the future? As a sidenote, I'd really appreciate if the Ubuntu guys would consider adopting this instance (don't take this as "you're doing a bad job", because you are not. Please take it as "please go through a bit more pain to make sure we all get a chance to agree the job is being done right, or at least that we all had the change to give input"), and at least post a question to pkg-sysvinit-devel about changes to the initscript packaging and tools. That's a three to five *days* delay I am asking about on an upload of one of the most critical pieces of infrastructure of the entire distro (be it Debian or Ubuntu), which seems quite fair to me. -- "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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]