On Wednesday 04 January 2006 17:37, Santiago Vila wrote: > Please read the archives of debian-policy. My own archive of policy only goes back to oktober 2004 and doesn't yield any matches, doing a websearch on debian-policy yields only the following threads: - http://lists.debian.org/debian-policy/2001/12/msg00064.html - http://lists.debian.org/debian-policy/1998/07/msg00218.html - http://lists.debian.org/debian-policy/1998/01/msg00239.html - http://lists.debian.org/debian-policy/1998/02/msg00351.html
None of which provide any arguments against beyond the single one you
mention in the FAQ (and which i adress below). If I've missed any please
provide pointers.
> This issue has been discussed several times there.
I've now read the relevant archived bugs of base-files (meaning the
following list, again if I missed any let me now):
#345921, #285105, #283089, #170639, #163743, #129892, #114642
The only extra 'argument' this yield is #285105's:
> You can make things to be very complex if you like, but
> as there are better ways to do the same things without changing the
> default /etc/profile, don't ask me to change /etc/profile to compensate
> that you decide to do things the complex way.
which is bogus as:
Adding less than 20 lines of extremely simple shell script isn't excatly
very complex. Espessially when the absence of those lines prohibits at
least 5 packages (see below) of providing a usefull service to their users.
All of those now have to request their users to do manual drudge work in
order to make full use of their services. This flies in the face of our
social contract's point 4, and can only be minimised by adding a script for
the admin to run that will do drudge work (apart from starting the script)
for him.
> There will always be people for which your feature request is a good
> thing, but IMHO the side effects of it will not compensate the
> benefits,
What Side affects?
The only real one noted AFAICT in any of the discussions to date is that it
would encourage other packages to "depend on environment variables in order
to get reasonable defaults".
That argument is void as
1) policy already forbids this
2) not providing a profile.d dir does not prevent packages packages ignoring
this policy requirement (one way would be to add a wrapper script around
the program that sets the environment variables)
3) for packages wanting to only set environment variables, the right place
to do this would be /etc/environment not /etc/profile
4) there's legitimate uses of profile.d
So please adress the following questions:
1) are there any realistic harmfull uses of profile.d that are not already
prohibited by policy?
2) - if so what are they?
- if not how do you justify not making one in the face of the fact that a
profile.d dir would allow at least 5 packages (see below) to provide
extra services to our users out of the box that they currently can't,
and point 4 of the social contract?
3) do you perhaps disagree with point 4 above? If so please provide some
reasoning.
> so I definitely need something more than "it would be useful
> for at least one package"
the bugs mentioned show desktop-profiles, user-es, and sysprofile needing
it.
A bit more investigation adds user-de and user-euro-es to the list
=> that's a minimum of 5 packages already, none of which are case of making
programs depend on environment variables in order to get reasonable
defaults. And all of which fall in the class if management infrastructure
to make live easier on our users.
And given the growing number of CDD's this number is likely to grow over
time.
> (for example, a policy amendment mandating the use of profile.d).
I see nothing in policy preventing a profile.d, on the contrary the quote
you give in the FAQ _supports_ it (as it prohibits misuse of it).
--
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)
pgploHJ3PHefo.pgp
Description: PGP signature
