On Sunday 23 April 2006 20:26, Russ Allbery wrote:
> Jari Aalto <jari.aalto@cante.net> writes:
> > What we need and what should have been done a long time ago, is to
> > modularize profile to /etc/profile.d/ where each program is resposible
> > for shipping reasonable defaults. Redhad has done this long time and
> > Cygwin does that too and it works very well.
> >
> > This way all the other issues concerning configuration would be nicely
> > modularized. There would certainly be several packages that would
> > benefit from /etc/profile.d/
>
> Please do not make the assumption that every shell reads /etc/profile or
> would read /etc/profile.d.
here's the current situation for Debian shells regarding a modularized on
login-script:
- fish, psh, zoidberg: each have their own modularized on-login script
- tcsh and csh: share the on-login script, not currently modularized but see
bug #351652 which is marked pending
- zsh: not currently modularized, but see bug #351663
- bourne compatible shells ((bash, dash, ksh, pdksh, mksh ) are all
using /etc/profile which is currently non-modularized and owned by
base-files.
Modularization has been requested repeatedly, see bugs #345921, #345921,
#285105, #283089, #170639, #163743, #129892, #114642, and now the bug
we're discussing.
As far as I can tell (note the qualifier, merely my impression) the
base-files maintainer is regarding any addition to /etc/profile as bloat,
and is opposed to modularizing the script.
-> that's 3 out of 6 on-login files modularized, one that will be
modularized, one rejection of modularization, and 1 that's undecided
-> none of the currently modularized on-login files have raised any problems
as far as I'm aware, even though each of them has been there for at least
a couple of months now.
> Policy does not make that assumption; that's
> one of the major benefits of the approach currently in Policy.
Policy (in section 9.9) says:
A program must not depend on environment variables to get reasonable
defaults.
(are there any other relevant sections, if so which?)
> If there are problems internal only to the ksh/bash family of shells that
> would be solved by /etc/profile.d, it may still be a good idea to create
> /etc/profile.d for their internal use,
Policy (in section 10.7.4) says:
If it is desirable for two or more related packages to share a
configuration file and for all of the related packages to be able to
modify that configuration file, then the following should be done:
One of the related packages (the "owning" package) will manage the
configuration file with maintainer scripts as described in the previous
section. The owning package should also provide a program that the other
packages may use to modify the configuration file.
Presence of an adaption mechanism for shared configuration files is
a 'should' directive in this case [0] and thus the current absense is a
definate bug according to policy (though not an RC one).
> but if other packages start putting things into /etc/profile.d assuming
> that they are then seen by all shells, it will break things quite badly
> and cause exactly the sort of problems that Policy was designed to protect
> against.
Any such breakage would be a violation of policy must directive (policy 9.9)
and hence an RC bug, which means that no such breakage should ever make it
into stable, and should be fixed ASAP in unstable when discovered.
-> this would be a valid objection if it weren't already forbidden by policy
-> assuming there are non-abusive uses cases for a modularized file this now
becomes an argument _for_ modularization, as policy 9.9. explicitly
forbids the known abusive use case, thus removing an otherwise valid
objection against from play.
As it happens there is indeed a non-abusive (IMO) use case, namely
configuration packages (and configuration frameworks) as used by CDD's.
Examples packages currently in the archive along those lines that would use
a modularized /etc/profile (as they currently have a blurb in their README
stating if you want this package to actually do what it's supposed to add
the following snippet to /etc/profile) are: desktop-profiles, user-es,
user-de, user-es, user-euro-es, and debian-edu-config ([2])
Also note that modularized/multi-level configuration is the preferred way to
adapt configuration for CDD's (as discussed at the CDD-devcamp in Malaga
[1]), as it's the only thing that always works (alternatives are debconf
preseeding, which only works before the intitial installation of the
packages, and cfengine (or similar) which can't be automated in a policy
compliant manner because it messes with conf-files of other packages)
[0] where this case = for use by bourne compatible shells, e.g. ksh
[1] http://lists.debian.org/debian-custom/2005/05/msg00014.html has S
has Sergio's summary of the devcamp meeting
[2] for the same reason that desktop-profiles needs it, not unlogical as the
latter is a generalization of the approach used by debian-edu-config to
customize the KDE-configuration, plans are to migrate debian-edu-config
to desktop-profiles for the etch version of debian-edu.
--
Cheers, cobaco (aka Bart Cornelis):
Attachment:
pgpyFnmfZrqiT.pgp
Description: PGP signature