Jobs under /lib instead of /etc?

Scott James Remnant scott at netsplit.com
Tue Oct 20 16:37:31 BST 2009


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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/upstart-devel/attachments/20091020/676f429f/attachment.pgp 


More information about the upstart-devel mailing list