Proposed guideline for init script files

[Michael Schwendt]

On Wed, 28 Feb 2007 18:50:44 +0100, Ralf Corsepius wrote:

> > Yes, the source rpms are available.
> Inapplicable to "joe average"

Does "joe average" fix bugs the way you've described?
 
> > > The point you seem to be missing is: I am talking about very few files,
> > > admins might have customized, e.g.
> > 
> > Customisation => %config files => done
> Yes! But this thread started with the FPC having decided to drop %config
> on init scripts, because the majority of FPC members doesn't consider
> them to be config scripts.
> 
> i.e. this decision has rendered this way of bug-fixing impossible.

Bug in an init-script => submit a bug report in bugzilla => expect an
update/errata package => why is an update of the package released which
doesn't fix the bug?

If the problem or fix is contradictory, disable the service, create your
own renamed initscript. Perhaps exclude the package from being updated,
since you don't trust the vendor anyway.

> > You refer to modifications which go beyond the scope of the software's
> > configuration files.
> As I said many times before: init scripts traditionally have been config
> files, ever since *nix'ish OSes exist (the origin is the early *nixes
> having used monolytic rc.local init scripts).

%config vs. %config(noreplace) vs. no %config

Isn't it too much of a risk to make init scripts a %config file that is
not kept in sync with package updates?

> > > * to work around bugs (I have stopped counting know how many times RH
> > > has messed up my xorg.conf, my named.conf over all these years,
> > 
> > Neither one is marked a %config file. Perhaps you refer to config
> > tools which have written to the files [at install/update-time]?
> True, xorg.conf isn't owned by any rpm, and named.conf seems to be
> ghosted, but ... if not them which files else are config files?

There are services, for which a default configuration is possible.
For other services, the configuration system is not flexible enough
(e.g. no include mechanism, no /etc/sysconfig usage, etc.), hence it
makes no sense to ship a default.
 
> > > * to add missing/experimental features.
> > > 
> > > * because they are developing on something.
> > > 
> > > * because they have 3rd party packages installed which might apply a
> > > different sub-package splits.
> > 
> > This is an entirely different beast. We've come a long way to get
> > confirmation, repeatedly, that 3rd party packages either are compatible
> > or aren't.
> At the very moment a package is being introduced into Fedora, any
> existing 3rd party package has no chance to be compatible

Are the 3rd party packages unmaintained?

Personally, I'm tired of that "3rd party" topic unless there is a

> Init scripts was the point this thread has started with. Now people have
> started a crusade against %config files outside of /etc.

If there's one thing you can annoy "joe average" with, it's config files
that are spread over the entire filesys. Add on top of that files in /var,
which are erased during package removal, because the packager has included
them in the package.
 
> bugs in init scripts. Just imagine an initscript having a typo in a
> rarely used "case/switch". The quick fix would be "fix that typo".
> 
> Without %config, the next update will blow this change away. If Fedora
> hasn't fixed it, ... your changes will be lost.

I am a proponent of fixing the vendor's broken package instead of trying
to work around the crap for too long. Even more since it's supposed to be
an open community project, which releases hundreds of updates. A "rarely
used case/switch"? So what? It's broken, isn't it? The vendor's stuff
should _just work_, let's not forget that!

Whether it's an init script or Python code or Perl code, doesn't matter.
You cannot mark everything %config(noreplace) just to be able to give your
temporary fixes precedence over official package updates. I have no idea
where that would start and where it would end (libs? binaries?).