On Thursday 05 January 2006 13:14, you wrote: > On Thu, 5 Jan 2006, cobaco (aka Bart Cornelis) wrote: > > On Thursday 05 January 2006 11:25, you wrote: > > > On Thu, 5 Jan 2006, cobaco (aka Bart Cornelis) wrote: > > > > What Side affects? > > > > > > As a user, I would become very upset if installing a package would > > > alter my $HOME/.profile. Whatever I do in my startup scripts > > > is not a business of any package, it's my business as a user. > > > > So you are seriously telling me that you believe that a user of > > user-es, user-euro-es, or user-de, all packages that are effictively > > mini-cdd's whose explicit goal it is to change the environment over to > > spansish or german would get upset that the environment is changed to > > actually support spanish or german? > > No, I mean that packages like user-es should not exist at all,
So CDD-like packages that set up a Debian system for a specific goal
(including adapting the shell environment for that need) should not exist?
Or only exist as part of the installer?
user-es is just a currently existing example of a CDD-like package, that
doesn't mean that other such packages can't or won't be conceived (given
the growing number of CDD's it's likely they will be, indeed
desktop-profiles came out of that corner).
> because the installer already asks the user about his/her
> language/charset/etc.
Things being avaible in the installer does not invalidate the need for a
mechanism to do this on an installed system (which makes up the majority of
our users I feel save to state).
> Every thing user-es "has" to do is actually a bug in some other package.
> What we have to do is to fix the real bugs in packages for which
> LANG=es_ES is not enough, not make things easier for packages like
> user-es to implement the wrong solution.
Regardless of the ideal situation, we live with the reality that user-es and
similar packages exist, have users, and would legitimately use profile.d
for something usefull and non-harmfull.
In short the above does not invalide user-es and consorts as valid users of
a profile.d directory.
> BTW, /etc/profile is not read by all shells, so whatever problem you
> want to "fix" by having a profile.d, modifying /etc/profile is surely
> the wrong solution.
/etc/profile isn't the first place I looked at to fix my bug. However it's
the only feasable place AFAICS: Neither ssh itself, nor PAM provide a
possibillity to source scripts at login. Both rely on shell initialization
for that. Which means I'll have to fix my bug one shell (or shell family)
at the time. For bourne-type shells this means /etc/profile.
If you happen to know of another place were I can source a script (so it
will be run for each ssh login) I'll be delighted to hear it. If not my
package still need a profile.d, and remains a valid example of usefull and
non-harmfull use of a profile.d directory
> Please, could we agree that we disagree and move to more productive
> matters?
we're having what sofar has been a rational and civil discussion that should
reach a conclusion at some point, and that adresses a real need.
The reasoning you state in the FAQ for not having a profile.d does not
adress all my arguments.
I've reasoned that:
1) policy allows a profile.d
2) policy prohibits misuse of it
3) there's currently at least 5 packages that would use it
4) given the above a profile.d should be added
You haven't countered my reasoning, nor have you invalidated my examples of
packages that currently need a profile.d directory. You also haven't agreed
with me that profile.d should be added, hence discussion is still ongoing.
Consequently I won't agree to disagree at this point.
--
Cheers, cobaco (aka Bart Cornelis)
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)
pgpdqlKohtCzq.pgp
Description: PGP signature
