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 -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
