On Friday 31 March 2006 16:25, you wrote: > > Attached are 2 versions of patches with 2 competing solutions to do so: > > 1) modularized_zlogin: this version of csh_login modularizes this file > > so any zsh scripts dropped into /etc/zsh/zlogin.d are sourced. -> IMO > > this is the preferred solution as: > > - it can be used by other packages also (e.g. the user-es, and > > user-de configuration packages could use this to configure things for > > zsh users) > > - doesn't clutter the system unnecessarely (though minimally) > > when desktop-profiles isn't installed . > > (if this is adopted I'll provide patches for user-es, user-de and > > similar configuration packags I know of to automate the setup > > they do for tcsh users) > > 2) with_bugfix_zlogin: this just adds the shell-snippet needed to fix > > bug #344030 directly into csh.login > > Yes, running bash on startup would seem less-than-ideal. > The other (modularized) solution has been strongly opposed for other > shells in the past (see for example the flame wars regarding sendfile).
As a another datapoint:
I know that the fish, psh, en zoidberg shells currently provide such a
modularized solution. And, more generally, the practice of having
modularized configuration files is widespread in Debian packages, to name
af few I find on my system:
- apache -> /etc/apache/conf.d
- apt -> /etc/apt/conf.d
- cron -> /etc/cron.{d,hourly,daily,monthly}
- bash -> /etc/bash_completion.d
- discover -> /etc/discover.conf.d & /etc/discover.d
- fish -> /etc/fish.d
- hotplug -> /etc/hotplug/blacklist.d & /etc/hotplug.d
- libpam -> /etc/pam.d
- logrotate -> /etc/logrotate.d
- psh -> /etc/pshrc.d
- sane -> /etc/sane.d
- sysv-rc -> /etc/rc[0-6S].d & /etc/init.d
- udev -> /etc/udev/rules.d
- x11-common -> /etc/X11/Xsession.d
- zoidberg -> /etc/zoidrc.d
Some searching on "sendfile profile.d site:debian.org" yields, the following
old threads on devel, which I guess is what you were referring to:
http://lists.debian.org/debian-devel/1998/07/msg02557.html
http://lists.debian.org/debian-devel/1999/06/msg00556.html
http://lists.debian.org/debian-devel/2000/06/msg00232.html
The arguments against in those threads seem to boil down to:
1) programs shouldn't depend on environment variables to work
-> this is the use case that everyone is afraid of, note however that it
is explicitly forbidden by policy nowadays, so doing so would be an RC
bug anyway.
Given that there are other use cases (see below), and that this
particular use is an RC bug now, the argument obviously is not a
good one.
-> as mentioned above there now is a use-case, were there didn't seem to
be one at the time of those threads, I'll explain:
Custom Debian Distributions are aimed at a narrower defined set of
users then Debian in general. This often allows choices for more
specific defaults/settings to be made that would be inappropriate for
the regular Debian package or Debian in general. This leads to the
creation of configuration packages whose sole purpose is to set up a
Debian system with the more specific default configuration suited for
the target group.
Obviously for this to be possible there needs to be a mechanism to do
so. At the cdd-devcamp in malaga last may [1] this topic was discussed
and the conclusion was that the used mechanisms for adapting the
configuration of a debian-system are (in order of preference):
1) modularized/multilevel configuration (such as a .d directory, or the
various config-set stacking mechanisms of the free desktop
environments)
2) debconf pre-seeding (con: only works if done before the installation
of
the preseeded package)
3) use cfengine (or similar frameworks) to change the configuration
files
themselve (con: can't be done automatically as it conflicts with
policy)
Regarding the on-login script of the various shells customization is
currently needed by the user-es and -de configuration packages, and to
fix the corner case bug #344030 of the desktop-profiles configuration
framework (which provides management of the config set stacking
mechanisms provided by the different desktop environments)
2) the default system environment should be minimal:
-> this actually becomes an argument for modularization IF a real need is
demonstrated by the reasoning that in such a case the modularization
means that the extra config is only there when needed, instead of
always because it's made part of the configuration shipped by the
basic package (even if that configuration disables it in the general
case).
-> note that the modularized_zlogin I provided has a minimal overhead
equal to testing for the existence of /etc/zlogin.d when no
configuration changes are present, which should be unnoticable on any
reasonable machine IMO.
[1] http://lists.debian.org/debian-custom/2005/05/msg00014.html
has Sergio's summary of the devcamp meeting
--
mvg, Bart Cornelis
pgpbEPtxs7ujh.pgp
Description: PGP signature
