Bug#364319: base-files: PS1 setting for *ksh (PROPOSAL: /etc/profile.d/)

[Russ Allbery]

cobaco (aka Bart Cornelis) <[EMAIL PROTECTED]> writes:

> /etc/profile is only used by bourne-compatible shells (of which tcsh
> isn't one). Most things can be writte in a way that's valid for all
> bourne-compatible shells, and any bits that can't can easily be wrapped
> in an appropriate if-statement

/etc/profile is *not*, however, used by all Bourne-compatible shells.
(One significant exception is zsh.)  Therefore, one cannot put things into
/etc/profile and assume that all Bourne-compatible shells will then see
them.

I don't think this really counters the rest of your argument, but it's
something to be aware of.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#364319: base-files: PS1 setting for *ksh (PROPOSAL: /etc/profile.d/)

[cobaco (aka Bart Cornelis)]

On Wednesday 03 May 2006 22:56, Bill Allombert wrote:
> On Thu, Apr 27, 2006 at 12:53:01PM +0200, cobaco (aka Bart Cornelis) 
wrote:
> > On Sunday 23 April 2006 20:26, Russ Allbery wrote:
> > > Jari Aalto <[EMAIL PROTECTED]> 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.
>
> I suggest the post below that detail how they use it and why
> this is not needed in Debian:
>
> 

I'll take the various arguments in that mail and give my take on it (correct 
me if I misinterpreted anything):


Debian shells are not required to be POSIX compliant, only /bin/sh.
In practice, I expect you will have a hard time to write shell scripts
that are valid for both tcsh and bash. 


/etc/profile is only used by bourne-compatible shells (of which tcsh isn't 
one). Most things can be writte in a way that's valid for all 
bourne-compatible shells, and any bits that can't can easily be wrapped in 
an appropriate if-statement




I would like to point out that the correct way in Debian to set
environnement variable for all users is to use /etc/environnement.


while very true, this is not a valid objection: 
- there's no way to conditionally set variables through /etc/environment.
  Sometimes you want to influence things through environment variables based
  on run-time tests (see for example my desktop-profiles package which does
  exatly that in order to fix a corner-case bug for those shells that allow
  it)
- configuration packages are another valid use case (see below)

One approach will never fit everyone: where one person sees bloat another
sees service. (I think we can all agree on that?).

In light of that it makes sense to offer a mechanism through which people 
can pick and choose the level of service/bloat they want. Which is exactly 
what modularizing /etc/profile would allow (through configuration packages 
that implement a particular level of service/bloat).

NOTE: this does not get in the way of base-files only offering a minimal
  level of bloat/service. 

As for the whole part of the mail critizing the redhat bloat, it's 
irrelevant if somebody wants to provide a configuration package 
implementing the exact set of bloat/service offered by redhat then that's 
fine. Only those users that want it will install it. 

> In that case, I would suggest to introduce a /etc/bashrc.d and
> /etc/kshrc.d rather than a /etc/profile.d.

Why split it per bourne-shell-variant? 
- Most things can be put in a way that's valid for all bourne-compatible
  shells (i.e. those using /etc/profile). 
- Those few bits that are specic to 1 shell-variant can easily be surrounded
  by an appropriate if-statement as the start of this bug illustrates.
-- 
Cheers, cobaco (aka Bart Cornelis)


pgplVzJPzMAII.pgp
Description: PGP signature

Bug#364319: base-files: PS1 setting for *ksh (PROPOSAL: /etc/profile.d/)

[Bill Allombert]

On Thu, Apr 27, 2006 at 12:53:01PM +0200, cobaco (aka Bart Cornelis) wrote:
> On Sunday 23 April 2006 20:26, Russ Allbery wrote:
> > Jari Aalto <[EMAIL PROTECTED]> 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.

I suggest the post below that detail how they use it and why
this is not needed in Debian:



> > > 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, 

In that case, I would suggest to introduce a /etc/bashrc.d and /etc/kshrc.d 
rather than a /etc/profile.d. 

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#364319: base-files: PS1 setting for *ksh (PROPOSAL: /etc/profile.d/)

[cobaco (aka Bart Cornelis)]

On Sunday 23 April 2006 20:26, Russ Allbery wrote:
> Jari Aalto <[EMAIL PROTECTED]> 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 

Bug#364319: base-files: PS1 setting for *ksh (PROPOSAL: /etc/profile.d/)

[Russ Allbery]

Jari Aalto <[EMAIL PROTECTED]> writes:

> I feel that the current /etc/profile or the future (if that plan is
> commenced) /etc/profile does not do any service whatsoever since it
> does not improve the situation.

> The policy's purpose should not to hinder development but guide it to
> sensible direction that serves the Debian community, the end users.

> 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.  Policy does not make that assumption; that's
one of the major benefits of the approach currently in Policy.

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, 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.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#364319: base-files: PS1 setting for *ksh (PROPOSAL: /etc/profile.d/)

[Jari Aalto]

| On Sun, 23 Apr 2006, Jari Aalto wrote:
| 
| > | Please note that policy says:
| > |
| > |A program must not depend on environment variables to get reasonable
| > |defaults.
| > |
| > | The way I read this, whatever "good" defaults you think should be in
| > | /etc/profile, should be instead coded in the shells themselves
| > | as a default when no PS1 is set at all.
| >
| > The quote has no relevance in this point, because program's behavior
| > is not dependent on it.
| 
| Yes, it is relevant. We are using the PS1 environment variable to get
| a reasonable default for the prompt. If we followed policy, we should
| not be setting the environment variable PS1 so that bash gets a good
| default for the prompt. Same for any other shell.
| 
| So, instead of breaking policy even more (by adding more defaults to
| override the shell's internal "bad" defaults), we should be thinking
| about following policy closer, which means removing PS1 settings
| completely from /etc/profile in the long run.
| 

I feel that the current /etc/profile or the future (if that plan is
commenced) /etc/profile does not do any service whatsoever since it
does not improve the situation.

The policy's purpose should not to hinder development but guide it to
sensible direction that serves the Debian community, the end users.

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/ 

Jari


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]