On Tue, 2009-10-20 at 17:11 +0200, Michael T wrote: > Do you actually expect that the average user of upstart will modify a > significant percentage of those scripts? If so then putting them in /etc > obviously makes sense. > I don't think that's relevant at all.
If the average user doesn't do it, or does it for very few, then having them in /etc isn't a problem *either* > I would personally expect them to be created and configured by package > maintainers in most cases though and not modified further in most cases > once they land on the package user's system. > Initially this is true, however remember that Upstart job configuration files are not shell scripts. They're intended to be much more readable, and editable: declaring what is run, not describing how to run it. If a sysadmin needed to change the options for apache, I would expect them to edit /etc/init/apache.conf directly and change the "exec apache" line. > In that case defaulting to a non-/etc location and allowing the user of > the system to place a locally modified version in /etc which would override > the package maintainers version would be more in keeping with current > practice > That is an absolutely idiotic practice. It means that package maintainer changes are simply not honoured, and worse still, you have no warning or notification that you're missing important changes from the package maintainer. If the package changed something critical, such as a path to a binary, your service would simply stop working! This is why package managers have conffile support in the first place. You get a chance to see that both you and the package maintainer have changed a configuration file, and you get to resolve the difference. > (that is what is done by udev hal policykit and many more). > udev and HAL certainly are not relevant here; udev's configuration scripts are much more like a programming language than anything else. You don't normally override files, you simply provide a later rule that changes what you want. HAL's likewise; the shipped rules provide the default processing, you can add further rules that can override on top. PK looks the same, the package provides a default policy which you can override. The important thing to remember though is this is all about changing the values of properties, not anything more complex. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist?
signature.asc
Description: This is a digitally signed message part
-- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
