[Fedora-packaging] Re: Draft: Init Scripts

Ralf Corsepius rc040203 at freenet.de
Tue Feb 20 14:07:03 UTC 2007


On Tue, 2007-02-20 at 08:43 -0500, Jesse Keating wrote:
> On Tuesday 20 February 2007 08:33, Ralf Corsepius wrote:
> > I don't see this - Separate config files only restrict the user to what
> > a vendor wants him to restrict to and what the vendor has taken into
> > consideration.
> >
> > It takes away the freedom of customization and takes away the freedom
> > extending init-scripts to what the vendor has not considered.
> >
> > Why would this be useful? The user has chosen to customize, so it's the
> > user's responsibility to handle this situation - If you take away
> > %config you are simply erasing, killing his "carefully handcrafted
> > solution" to a real world problem. - I can't find this helpful.
> 
> And I can't see any difference between this an any other script on the file 
> system. 
As I wrote before, if you want to take this too extremes, yes the same
consideration can also be applied to any script in the system and one
could go so far to state rpm not allowing this to be a bug.

The difference between an arbitrary script and /etc/init.d scripts is
their history of init.d and their role. 

Nobody expects arbitrary scripts to customizable. 
Instead, people resort to other means, such as repackaging rpms, adding
custom scripts to /usr/local (exactly this is what /usr/local is for) or
elsewhere (/opt, ~/bin, /root/bin).

Such workaround aren't easily applicable to init.d scripts.

>  So unless we extend it so that all editable scripts become %config, 
> I don't see this special casing being helpful, instead its promoting 
> upstreams to continue to use init scripts for configuration.
Let me ask differently: What is the problem you are trying to solve?
I don't see any. 

Files under /etc/* are defined as config files, therefore /etc/init.d
are config-files by definition. This matches their history, matches
tradition, matches common practice, is helpful to users and makes no
difference to a vendor, and also makes no difference to the vast
majority of users.

To the remaining minority of users it makes a substantial difference. It
at least forces them to redesign their "customizations" because any
update will trash their customizations.

Ralf







More information about the packaging mailing list