Most Fedora init scripts incorrectly install into %_initrddir (/etc/rc.d/init.d) instead of /etc/init.d as mandated by LSB. Adding to the issue it appears that the intent is to make current practice the standard rather than the LSB standard(1)(2). Depending on which init page on the wiki you view you get the impression that Fedora guidelines should adhere to LSB(3). To quote from the standard(4): "An init script shall be installed in /etc/init.d (which may be a symbolic link to another location), by the package installer." It seems like either the draft, all packages with init scripts, current practice, and wiki should be modified or the redhat-lsb package needs to be dropped from the distro and LSB adherence/compliance statements removed. 1) http://fedoraproject.org/wiki/PackagingDrafts/InitDir 2) https://www.redhat.com/archives/fedora-packaging/2008-March/msg00131.html 3) http://fedoraproject.org/wiki/FCNewInit/Initscripts 4) http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/initsrcinstrm.html
/etc/init.d is a symlink to /etc/rc.d/init.d , so they both point to the same place ultimately. What's the problem here?
Imo, taking this to the packaging comittee @ fedora-packaging list (whom are responsible for packaging policy) is a better forum for such discourse, not bugzilla.
> What's the problem here? The problem is that the standard specifically says "... installed in /etc/init.d ... by the package installer." whereas your packages are installing into /etc/rc.d/init.d per the rpm macro %_initrddir. Apologies if that wasn't clear. /etc/init.d may be a symlink, but that doesn't mean you can install wherever and be compliant. I do not subscribe to any Fedora email lists, I will not sign a CLA (and therefore cannot edit the wiki), and that leaves me bugzilla. It was either file a bug against every Fedora package (time prohibitive) or file against redhat-lsb, which seemed to me to be a little cleaner. You are more than welcome however to bring this bug to the packaging committee's attention (and I hope that you do).
I'll raise the issue with the committee sure, but I'll be honest that I don't subscribe to your view of extreme brokenness (to me, it's a cosmetic issue). Imo, without an advocate for the cause (ie you), the likelihood of seeing change is smaller.
This is really silly. LSB says: "An init script shall be installed in /etc/init.d (which may be a symbolic link to another location), by the package installer." The Fedora initscripts are being installed into /etc/init.d (which is a symbolic link to /etc/rc.d/init.d) by the package installer. They're just owned by the packages in /etc/rc.d/init.d. This is not an LSB violation.
Correct. Moreover: 1) system init scripts are not required to adhere to the LSB standard. 2) the specific path is a deprecated part of the standard
as to comment 6, element #2 http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/etc.html is unambiguous: Future Directions: These directories are required at this version of the LSB since there is not yet an agreed method for abstracting the implementation so that applications need not be aware of these locations during installation. However, Future Directions describes a tool, lsbinstall, that will make these directories implementation specific and no longer required. The tool in question (lsbinstall,) was in the talking stages at LSB 3, was 'not ready for prime time', and will not appear in initial LSB4 so far as I can tell from participation with the LSB ML, bugtracker, and on the weekly call. Absent 'an agreed method for abstracting', it is clearly premature to call elimination of /etc/init.d/ 'a deprecated part of the standard'; it simply is not. If you have a URL to the contrary, to quote the terse: https://bugzilla.redhat.com/show_bug.cgi?id=438421#c1 Examples? Sauce for the goose is tasty on the gander as well
Comment 4: I'd like to make it clear that "extreme brokenness" is not my wording or in any way representative of the original bug filing intention. The assertion is not that current behavior is broken (the scripts obviously work) but that their installation mechanism is not standard compliant. Comment 5: I'm not sure where the ambiguity in reading is, the statement is pretty clear that things must install to /etc/init.d. Where they end up on the system is irrelevant, and where /etc/init.d points to is irrelevant. The following, by my reading, installs to /etc/rc.d/init.d: install %{name}.rc %{_initrddir}/%{name} Which again violates the plain language of the standard (a position held by OpenSuSE as well for a point of reference). Comment 6: I see nothing that marks the init script section as deprecated or optional, would you mind pointing to what you're talking about (I very easily may have missed it). There is a note that says "The requirement to install scripts in /etc/init.d may be removed in future versions of this specification." however 3.2 is the latest version of the LSB specification so I'm having trouble understanding where it's deprecated. And finally, I think most people agree that %_initrddir is a poorly named macro (initrd conjures images of kernels, not sysvinit) so why would you want to a) perpetuate its use, and b) mandate it? IIRC there was even a rpm.org thread about removal.
"May be removed" certainly related to implicit, if not direct, deprecation, i.e., "don't rely on this." In any case, my point #1 still applies. Fedora scripts can be installed in /etc/I-Don't-Care-What-The-LSB-Says-Neener-Neener.d/, and Fedora will still be LSB compliant. All the standard requires is that you *handle* LSB-compliant scripts installed in /etc/init.d; it says nothing about what the system native implementation is. If we wanted to treat all system scripts as LSB scripts, all system scripts would: - be set up with /usr/lib/lsb/install_initd, not /sbin/chkconfig - use only /lib/lsb/init-functions, not /etc/init.d/functions - use only registered names for their script names We don't specify any of those for system scripts to adhere to, nor should we (as it would involve essentially making every package that installs an init script depend on cups and X). System scripts *are not required to be LSB scripts*. Ergo, complaining that the script draft specifies a directory (which resolves to the in-spec directory) without actually worrying about the *functional* parts of the spec is just needless pedantry.
May be deprecated in a future version does not equate to "don't rely on this"; were that the case standards would cease to exist. Really, does this need to be debated? All standards will eventually be deprecated, and in this instance I'm talking about a simple sed -e 's/%_initrddir/%_sysconfig\/init.d/g' *.spec, I'm not asking for you to teach the nation's children to read (to quote a US movie). I see nothing in the standard that supports your position. I'm asking for something straight forward, if you have a position on the standard support it with the standard and references. I've done that in the bug report. Despite your hand waiving both you and spot have failed to come even close. You've done a wonderful job of supporting my position that Fedora is not LSB compliant, and simultaneously done nothing to prove you are. Listing all the ways in which you fail to comply hardly justifies your position, opinion on whether I subscribe to pedantry notwithstanding. To quote a friend, you can't be a little pregnant, either you are or you aren't.
Re: comment #5 "An init script shall be installed in /etc/init.d (which may be a symbolic link to another location)..." Further, packaging targets in symlinked directories (as you seem to be suggesting in comment #10), is bad packaging practice. Jason, how do you suggest to reconcile this? Wait, please don't, not here anyway. Let me re-iterate, bugzilla is *not* a forum for discussion/argument on standards. I can guarantee continuing on here (and repeatedly reopening this bug) serves no useful purpose and is counter-productive. Please take it to a more appropriate forum, like an lsb list (or fedora-packaging), so that a proper discussion (with a wider audience) can be had. If you refuse to do so, that's fine, just please stop spamming bugzilla. Please, please, pretty please.
> I see nothing in the standard that supports your position. My position is simple. Nothing in the LSB requires that system scripts conform to the LSB standard for LSB application-deployed scripts. Fedora system scripts already do not conform to the LSB standard. Therfore, packaging policies on Fedora init scripts do not need to conform to the LSB standard for LSB-compliant application init scripts. Therefore, the fact that the guidelines do not conform to the *letter* of the standard, even though the scripts end up in the same place is *NOT A BUG*. The only way in which it would be relevant is if we're attempting to codify in the standard that any package that installs init scripts in Fedora should be packaged as an LSB-conforming application. We're not doing that. > I'm asking for something straight forward Is that clear enough for you? > You've done a wonderful job of supporting my position that Fedora is > not LSB compliant, and simultaneously done nothing to prove you are. *Sigh*. If you want chapter and verse, here's chapter and verse. 20.2: Conforming applications ... may install one or more init scripts. Note: LSB *applications*. Not system provided scripts. Similarly in 20.3. 20.3: The comment conventions described in this section are only required for init scripts installed by conforming applications. Conforming runtime implementations are not required to use this scheme in their system provided init scripts. Again, system scripts need not apply. 20.4: Conforming applications may install one or more initialization scripts (or init scripts). An init script shall be installed in /etc/init.d... Again, conforming *LSB applications*. Not system scripts. I'll repeat: the LSB init scripts standard is about *how LSB-conforming applications should package and write their scripts*. It says pretty much nothing about how the system implementation should work under the covers, *as long as the implementation can handle these scripts*. An upstart-based system can still be LSB-compliant, as long as they handle LSB scripts, and upstart events certainly aren't going to installed in /etc/init.d. I'll agree. I'm not trying to teach the nation's children to read. However, I am sort of expecting that people reading this be able to. If you have a problem with the packaging spec, take it up on fedora-packaging list. This is not the appropriate forum, in any case. Further comments here will be ignored.