Re: [kooij@mpn.cp.philips.com: Bug#17545: sendfile: sendfile modifies /etc/profile which is owned by bash]
On Tue, 27 Jan 1998, Martin Schulze wrote:
> > Package: sendfile
> > Version: 1.6-3
> >
> > The postinst and postrm "manually" change /etc/profile, this is
> > against policy.
> >
> > The postinst also writes to /etc/services, which is owned by netbase.
> > Perhaps in this case you should contact the netbase maintainer to have
> > him add the necessary entries to /etc/services.
>
> I don't know how to deal with this?
>
> We don't have /etc/profile.d like there was on the iConnect master.
> There is no other way to add this programm at the moment.
To be honest, I wouldn't really know either :-)
Nevertheless, policy has been set and adding to /etc/profile violates it.
I can see the needs to be able to add entries in files like:
/etc/profile, /etc/environment, stuff in /etc/skel, user's .*rc files
For a long while, an unspoken policy has been in place to do nothing with
such files, creating a default installation free of any customizations.
Only recently, the system is tending to provide more reasonal defaults not
only in the technical sense, but also wrt. customization. Maybe it is time
now to start thinking about this in a structured manner.
Thinking about this, the Debian menu system comes to mind. It has a very
elegant and coherent way to provide defaults by itself, let packages
change these, let sysadmins tweak it better and let users put yet more
customizations of their own in.
Starting with an implementation for /etc/profile, /etc/environment and
whatever else I'll forget to mention anyway, a good system may eventually
be extended to provide hooks for more configuration files and maybe
a systematic approach to administration of config-files (don't tell this
to the folks who've been battling on debian-admintool ;-)
The current trend is to require every package that contains conffiles that
other packages might want to write to, to provide an interface to its
conffiles to other packages. In the long term I think that a model where
packages merely provide standardized hooks for a central
coordinator/broker is a better way to go.
> Concerning /etc/services. We don't have a mechanism for adding
> entries to it. As this service wasn't present at the first
> released /etc/services file packages may not depend on its
> presence - this means that it has to be added manually. So
> what to do?
AFAIK, /etc/services is supposed to be more of a "constant" than a
configurable thing. IIRC it has in the past been suggested already that
the netbase maintainer should add needed entries to it and release a newer
version of netbase. Maybe the netbase maintainer should be asked about his
recollections/opinion regards these matters.
> If this should be discussed in debian-policy please forward it
> there.
I think it makes sense to start a topic here, yes (besides, people are
getting rather emotional about the amount and nature of traffic on
debian-devel.)
Cheers,
Joost
Reply to: