I'm in the process of cleaning up an initscript I own to meet LSB
standards but this has left me with several questions primarilary in the
area of start up ordering.
FYI, I'm utilizing the guidelines found here:
https://fedoraproject.org/wiki/FCNewInit/Initscriptshttps://fedoraproject.org/wiki/Packaging/SysVInitScript
In the past we used hardcoded chkconfig start/stop numbers to control
the order in which services were started and stopped. My understanding
is that is deprecated (although still supported) but the preferred
method is the LSB boot facility declarations (Required-Start,
Should-Start, Required-Stop, Should-Stop). Correct?
The section describing facility names seems a bit vague to me:
Shouldn't the guidelines *require* that the LSB block have a Provides:
declaration which at a minimum includes a name matching the initscript?
If you read between the lines the guidelines seem to suggest that but
it's not clearly an explicit mandate. Without that I don't see how one
can use the boot facility dependencies for other services. In other
words if I depend on mysql running then mysql must have declared it
provides mysql, or is that provides implicit as opposed to explicit?
In addition to the explicit eponymous Provides: what about virtual
provides? Do we have a set of virtual provide names? (e.g. mailserver,
webserver, or ldapserver)
The guidelines also state that an initiscript should never be marked as
%config and instead import configuration settings from
/etc/sysconfig/$name. But what about the case where a service may have a
variety of boot dependencies depending on how it's configured? For
example a service might be configured to optionally use mysql vs.
postgres, or to use LDAP vs. SQL so it will have boot dependencies on
particular services which cannot be hardwired ahead of time. I doubt the
LSB block parsing logic handles "includes" from /etc/sysconfig, or does
it? Assuming not then the initscript has to be marked as %config right?
--
John Dennis <jdennis(a)redhat.com>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
Hey Ivana,
So the FPC met yesterday and voted against the Man Pages Draft as a Packaging
Guideline. The basic reasoning is that the justification for voting against
the previous man pagesdraft:
https://fedoraproject.org/wiki/MAN_pages_which_exists_in_other_places(draft)
was applicable here as well. In particular, this was the conclusion of
discussion of that other draft:
"This draft conflicts with the general practice that Fedora packagers should
be working to send improvements directly to upstream. Anyone who feels
motivated to dig in other distributions for patches or improvements should
feel free to do so, but it is not something that the FPC felt should be
codified into the guidelines. "
The FPC did offer a few thoughts on what could be done with this, though:
* If FESCo wanted to make a policy that we should be striving to have
some sort of coverage goal for man pages, then we'd definitely include
packaging guidelines so that reviewers and packagers would know that
making man pages is required. This could be a FESCo policy like "Fedora
wants to have 100% coverage of binaries in /bin, /sbin, /usr/bin, and
/usr/sbin"
* I'm going to be working on ways that we can restructure the Packaging
Guidelines to be better organized this weekend (as part of FUDCon). One
aspect of that is figuring out how to make FESCo policies, non-guideline
hints for packaging, and other things that are optional or just
non-Guideline material better integrated so that packagers and reviewers
can both know what's necessary for a Fedora Package and what things they
can do to make their package really shine. Finding a place for things
like this draft there could be good.
+ As part of that, we do currently have a page that lists tricks and tips
for making better packages that go above and beyond the Guidelines:
https://fedoraproject.org/wiki/Packaging_tricks
That wiki page is open for anyone to write to so you should be able to
add your man page stuff there (or link from it) for the time being.
-Toshio
