Proposed guideline for init script files

[Ralf Corsepius]

On Wed, 2007-02-28 at 18:12 +0100, Michael Schwendt wrote:
> On Wed, 28 Feb 2007 17:17:16 +0100, Ralf Corsepius wrote:
> 
> > > > Well, the more I think about it, the more I am inclined to like the idea
> > > > to consider rpm's default behavior to override any modified file as a
> > > > bug.
> > > 
> > > The bug is that somebody modifies installed non-config files without using
> > > the packaging system.
> > == You want users to package their customizations. Given the limitations
> > of rpm this means to rebuild the packages.
> 
> Yes, the source rpms are available.
Inapplicable to "joe average"

>  Using local repositories is possible,
> too, and highly recommended if you want to install the same fix on
> multiple machines.
How do you think did I get into packaging? Because it's fun? 
No. Because the limitations of rpm, how it had been used by vendors (%
config) and vendors not having been able to provide bug-fixes in
reasonable time had forced me into it.

> > 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.

> 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).

> > * 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?

> > * 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

> > * because traditional packaging of packages were designed to be modified
> > (e.g. site-wide app-defaults)
> 
> In non-%config files?
Init scripts was the point this thread has started with. Now people have
started a crusade against %config files outside of /etc.

> > > And what behaviour would you prefer during a dist-upgrade? That RPM
> > > refuses to install new binaries, because the user has replaced them with
> > > modified files?
> > Nope, I'd prefer an rpm that refuses to replace modified _files_ (Note:
> > files, not packages) and backs them up (similar to *.rpmsave or
> > *.rpmnew). Of cause such an rpm also would have to have a "--force" mode
> > to forcibly replace such files.
> 
> *.rpmnew for such files would be a show-stopper. Just imagine how RPM
> could not guarantee integrity of an installed set of packages, if it
> installed any updated files as *.rpmnew.
> 
> I can think of RPM creating backups of any files, which don't belong into
> any package, before overwriting them. But the problem is selfmade:
> modifying files which belong into packages, and mixing unpackaged files
> and packages in an installation.
Again matter of POV: It's often the easiest way to fix (often trivial)
bugs, and it's often the easiest way to add features.

>  This bears the risk of breaking in many
> places. It's also one reason why the filesys has places like /usr/local
> and site-specific install locations.
This doesn't help when it comes to packaging bugs below /etc, esp. to
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.

Ralf