Policy regarding /etc/profile.d
Hello.
For a lot of time, I was reluctant to modify /etc/profile to support
/etc/profile.d because my understanding of policy, namely this:
A program must not depend on environment variables to get
reasonable defaults. (That's because these environment
variables would have to be set in a system-wide
configuration file like <file>/etc/profile</file>, which is not
supported by all shells.)
was that profile.d was never intended to be used by Debian packages,
only by the final user.
[ The profile.d directory was finally added because it was required by
some LSB compliance test ].
But today I've just realized that what I feared is happening: package
maintainers have started to use profile.d "because it's now supported":
$ zcat Contents-amd64.gz |grep etc/profile.d|sort -k 2
etc/profile.d/Z99-cloud-locale-test.sh admin/cloud-init
etc/profile.d/modules.sh devel/environment-modules
etc/profile.d/tinyos.sh devel/tinyos-source
etc/profile.d/alc_env.sh electronics/alliance
etc/profile.d/alc_env.csh electronics/alliance
etc/profile.d/qmf.sh libs/libqmfmessageserver1
etc/profile.d/vte.sh libs/libvte-2.90-common
etc/profile.d/vte-2.91.sh libs/libvte-2.91-common
etc/profile.d/Z97-byobu.sh misc/byobu
etc/profile.d/PackageKit.sh misc/packagekit-command-not-found
etc/profile.d/undistract-me.sh misc/undistract-me
etc/profile.d/sendfile net/sendfile
etc/profile.d/SBMLToolbox.sh science/sbmltoolbox
etc/profile.d/bash_completion.sh shells/bash-completion
Do we need a paragraph in policy saying explicitly "you should not use profile.d"?
Thanks.
Reply to: