Re: run-parts for /etc/profile?
Marc.Haber-lists@gmx.de (Marc Haber) wrote:
> > Because it is Debian's policy for software to not rely on any specific
> > environment variables being set.
> Even if the Debian system itself won't need it, it would make life for
> admins a lot easier. We do like predefining environment variables for
> our users :-)
Maybe for lazy admins. You are trying to shift the responsibility
of configuring the system from the local system administrator to the
package maintainers. The maintainer should ensure that the software in
his package works. That in itself is a task that is large and complex
enough. It's up to the system administrator to activate optional
features, and for this I believe that run-parts is overkill.
> > Besides, it is generally evil to go mucking around in everyone's
> > environment just because a new package was installed.
Agreed.
joy@cibalia.gkvk.hr (Josip Rodin) wrote:
> Also, one other idea: /etc/aliases files that come with various mailer
> daemons all have aliases like 'disk: root' and such, that sounds a
> bit silly, but there is a limited number of aliases in this file that
> are needed by programs, so it's reasonable. But there is a problem
> -- these aliases are not inserted on an upgrade of that file (if it
> already has them).
> For example: on a fresh install, the default file gets installed. Fine.
> But, if there is some admin that will erase the default file, and put
> only his own aliases that do not include those from the default file,
> and every time when his mailer daemon gets updated, dpkg will ask him
> does he wish to overwrite - and he'll most probably say no - and the
> default aliases will never get to his /etc/aliases file.
> It shouldn't be such a hard thing to do, someone with sufficient
> knowledge of sed/awk/whatever can do it.
The problem here is that the admin said "no" and did not follow up to see
what had changed in the file. Is it so difficult for the admin to set
off his changes between a set of comments, which he can use as a guide
to update the file when this situation occurs? I definitely prefer this
method to having a set of unknown scripts hack up my config file in the
background without my knowledge.
Brian
Reply to: