Bug 438357 - packaging policy on init scripts violates LSB standard
packaging policy on init scripts violates LSB standard
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: redhat-lsb (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Lawrence Lim
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-20 11:16 EDT by Jason Corley
Modified: 2014-03-25 20:55 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-24 14:06:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jason Corley 2008-03-20 11:16:09 EDT
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
Comment 1 Rex Dieter 2008-03-20 11:27:13 EDT
/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?
Comment 2 Rex Dieter 2008-03-20 11:28:35 EDT
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.
Comment 3 Jason Corley 2008-03-20 12:22:25 EDT
> 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).
Comment 4 Rex Dieter 2008-03-20 12:32:50 EDT
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.
Comment 5 Tom "spot" Callaway 2008-03-20 15:56:58 EDT
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.
Comment 6 Bill Nottingham 2008-03-20 16:21:49 EDT
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
Comment 7 R P Herrold 2008-03-20 16:53:11 EDT
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 8 Jason Corley 2008-03-20 16:56:34 EDT
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.
Comment 9 Bill Nottingham 2008-03-20 18:18:04 EDT
"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.

Comment 10 Jason Corley 2008-03-21 02:47:34 EDT
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.
Comment 11 Rex Dieter 2008-03-21 09:24:30 EDT
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.
Comment 12 Bill Nottingham 2008-03-24 14:06:02 EDT
> 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.

Note You need to log in before you can comment on or make changes to this bug.