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