Bug#345921: add profile.d dir so packages can add shell snippets
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
Bug#345921: add profile.d dir so packages can add shell snippets
On Thu, 5 Jan 2006, cobaco (aka Bart Cornelis) wrote: What Side affects? The file /etc/profile is similar to .profile, except that it is global. 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. Allowing /etc/profile.d would be the equivalent of allowing packages to modify the user's startup files. It would break the principle of least surprise, and therefore a bad thing. Moreover, dpkg usually asks about changes in configuration files in /etc. Having a profile.d would be the equivalent of dpkg being allowed to change /etc/profile without the user being prompted about the change. The principle of least surprise would be broken again. So no, I do not believe in legitimate uses of profile.d. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345921: add profile.d dir so packages can add shell snippets
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? For desktop-profiles and sysprofile this argument is even more bogus as the profile.d snippets those packages add don't change the environment by themselves, any environment changes resulting from running those snippets are consequence of parsing bits of configuration under admin control (i.e. when the admin hasn't changed the default configuration nothing will be changed). Allowing /etc/profile.d would be the equivalent of allowing packages to modify the user's startup files. It would break the principle of least surprise, and therefore a bad thing. Are you seriously positing that the principle of least surprise would have a user of user-es whose package description starts with: This package allows administrators to set the default language (es_ES) and encoding (ISO-8859-1) used by a Debian GNU/Linux System (and its applications) easier. be surprised when the environment is actually changed that automatically to do exactly that when installing the package? If so I find that a rather insulting view of our users reading comprehension (not even intelligence). In the case of desktop-profiles, which is a management framework that lets the admin set up configuration sets do you really believe that the principle of least surprise would be to not have those admin-specified settings apply in the corner-case of logging in through 'ssh -X'? If so the user that filed #344030 definately doesn't agree with you on that (nor do I) Moreover, dpkg usually asks about changes in configuration files in /etc. Having a profile.d would be the equivalent of dpkg being allowed to change /etc/profile without the user being prompted about the change. The principle of least surprise would be broken again. nope, all it does is clearly identify the parties responsible for each bit of configuration, and making it possible to do that configuration in the first place without messing with other packages conffiles. Given that this exact mechanism is used by plenty (core) packages such as: - the Xserver (/etc/X11/Xsession.d) - lograte (/etc/logrotate.d) - sysv-rc (/etc/rc[0-6].d) - cron (/etc/cron.d) - discover (/etc/discover.d) - apache (/etc/apache/conf.d/) -... - the position that this a profile.d directory would break the principle of least suprise is obviously not realistic. Especially since the earlier bug rapports on this issue mention that Redhat, Mandrake, Suse and Gentoo do have a profile.d (that's pretty much every major distro that's not Debian), so at least for users that switch (and anecdotal evidence suggest that covers most Debian users) this would definately not violate the 'principle of least surprise' So no, I do not believe in legitimate uses of profile.d. please counter the specific examples I've given above if you still feel that way -- 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) pgpOTmY2btkha.pgp Description: PGP signature
Bug#345921: add profile.d dir so packages can add shell snippets
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, because the installer already asks the user about his/her language/charset/etc. 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. 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. Please, could we agree that we disagree and move to more productive matters? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345921: add profile.d dir so packages can add shell snippets
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
Bug#345921: add profile.d dir so packages can add shell snippets
On Thu, 5 Jan 2006, cobaco (aka Bart Cornelis) wrote: I've reasoned that: 1) policy allows a profile.d Policy allows a lot of things, but that does not mean that every thing which policy allows should be implemented. Point 1 invalid. 2) policy prohibits misuse of it It *will* be abused, and the abuse will be worse than the supposed benefits. The probability of that happening is 1. Point 2 invalid. 3) there's currently at least 5 packages that would use it Those packages should probably not exist. Point 3 invalid. That number is so low that I'm wondering why on earth I am still replying to you. Debian has more than 15000 packages, and we have survived very well without the profile.d thing. Just because some packages would use it does not mean it is a good idea. 4) given the above a profile.d should be added I'm sorry, but I do not follow your line of reasoning. If it is so much important for you, modify policy so that it regulates the use of profile.d. Until then, it will not be added to base-files. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345921: add profile.d dir so packages can add shell snippets
On Wednesday 04 January 2006 15:18, you wrote: please use the wontfix tag instead of closing, this seems to be a textbook case of what the tag is for (and would avoid the whole 'again' frustration'). Sorry, but I have never been a big fan of the wontfix tag. Either a bug is a bug and should be fixed, or it is not and should be closed. There is no excuse for not reading the documentation. shrug A FAQ isn't the primary place were I expect to find information about a feature request, the BTS is (BTS is documentation also). Given your comment 'not again' I don't seem to be alone in that expectation. = by all means close the bug, instead of using wontfix, but do realize that the repeated filing of this request seems a logical consequence /shrug You are welcome to propose a policy change mandating the profile.d thing. why would we need a policy to allow it? I don't see anything in policy that prevent's this. Until then, I consider the profile.d thing as something harmful, as it would open a can of worms. Given that: - policy already prohibits your stated harmfull use of profile.d (you helpfully give the quote in the FAQ) - there are non-harmfull uses of profile.d. The reason I filed this bug, which I explained in my previous message, gives one example. I'm at a loss as to what exactly the 'can of worms' is that would be opened. On the other hand providing it would allow me to fix an existing bug filed by one of our users. In short it's the responsibility of Debian Policy to stop packagers from doing harmfull things, not base-files. And this is stopping me from providing a solution for a reported problem by one of our users (atmittedly in an edge case), which flies in the face of the social contract IMO. Remaining questions: - Are there any harmfull uses of a profile.d dir that the policy quote given in the FAQ doesn't adress (in the absence of such the can of worms thing is not a valid argument)? If so what are they? - Or do you perhaps disagree with my assertion that the use I would put it to is non-harmfull? -- 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) pgpVE5RExvaHh.pgp Description: PGP signature
Bug#345921: add profile.d dir so packages can add shell snippets
Please read the archives of debian-policy. This issue has been discussed several times there. 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, so I definitely need something more than it would be useful for at least one package (for example, a policy amendment mandating the use of profile.d). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345921: add profile.d dir so packages can add shell snippets
Package: base-files
Version: 3.1.9
Severity: wishlist
Tags: patch
Adding the snippet below to /etc/profile modularizes /etc/profile so
packages can drop snippets they want to add into an /etc/profile.d dir and
have them picket up.
Several other packages in Debian have similar mechanisms in place the
advantage being that packages can add configuration snippets they need in a
policy compliant manner without needing to bother you guys for each change,
and without having the snippet when the package that needs it isn't
present.
I currently need this in order to fix a shortcoming of the current
desktop-profiles package (see beastie #344030 for details)
begin snippet
# Allow packages to add stuff in a policy compliant manner
# approach is essentially copied form Debian's /etc/X11/Xsession file
SESSION_DIR=/etc/profile.d
run_parts () {
# until run-parts --noexec is implemented
for FILE in $(/bin/ls $1); do
if expr $FILE : '[[:alnum:]_-]\+$' /dev/null 21; then
if [ -f $1/$FILE ]; then
echo $1/$FILE;
fi;
fi;
done;
}
# If $SESSION_DIR is a directory, source all scripts in it.
# We source instead of execute since we want scripts to be able to set
# variables, and define functions.
if [ -d $SESSION_DIR ]; then
SESSION_FILES=$(run_parts $SESSION_DIR);
if [ -n $SESSION_FILES ]; then
for SESSION_FILE in $SESSION_FILES; do
. $SESSION_FILE;
done;
fi;
fi;
end snippet
--
Cheers, cobaco
/\ ASCII Ribbon Campaign
\ / No proprietary formats in attachments without request
X i.e. *NO* WORD, POWERPOINT or EXCEL documents
/ \ Respect Open Standards
http://www.fsf.org/philosophy/no-word-attachments.html
http://www.goldmark.org/netrants/no-word/attach.html
pgpOFhsBPpd1V.pgp
Description: PGP signature
Bug#345921: add profile.d dir so packages can add shell snippets
On Wednesday 04 January 2006 13:09, you wrote: On Wed, 4 Jan 2006, cobaco (aka Bart Cornelis) wrote: Package: base-files Version: 3.1.9 Severity: wishlist Tags: patch Adding the snippet below to /etc/profile modularizes /etc/profile so packages can drop snippets they want to add into an /etc/profile.d dir and have them picket up. No, not again. please use the wontfix tag instead of closing, this seems to be a textbook case of what the tag is for (and would avoid the whole 'again' frustration'). Please read /usr/share/doc/base-files/FAQ. had missed this, reading now ... as I'll explain below I don't feel it addresses the reason I want this: Q. Why does Debian not have a profile.d directory, like other distributions? A. Because no Debian package needs it. Debian policy says: A program must not depend on environment variables to get reasonable defaults. This policy has been very successful so far. If the default install had a profile.d, people might think it's ok to use it for a Debian package, when in fact policy does not support such thing. There's other reason's then setting environment variables _needed_ by a program to run to want a profile.d directory. For example adding some piece of management infrastructure for the admin, which is wat desktop-profiles does: essentially I need to run the profile activation script when logging in with 'ssh -X' (as the Xsession.d scripts then don't get run that way). That script parses configuration files, and based on the settings in them sets up the admin-controlled configuration sets to be used (which might differ according to usergroup, or any other testable condition) by the graphical apps of the various desktops. Programs will work just fine when those sets aren't loaded, they just won't be using the settings the administrator wants them to use (which might necessitate the user duplicating eacht setting the admin made, or might allow the user to avoid a mandatory setting). More generally there's the point of CDD's (desktop-profiles came out of that corner), the whole idea of which is to have a standard Debian, but configured to suit a specific target group/goal/situation. The only way to do this _inside_ of Debian is for packages to allow other packages to add bits of configuration (essentially the configuration package becomes the admin doing the initial setup). The other option is to fork each package needing configuration with all the extra work and effort that ncessitates. As the above (hopefully) makes clear there's currently at least 1 Debian package which _does_ need it, and with the growing number of CDD's there's bound to be more sooner or later. -- 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) pgpSwHHwLiz8C.pgp Description: PGP signature
Bug#345921: add profile.d dir so packages can add shell snippets
On Wed, 4 Jan 2006, cobaco (aka Bart Cornelis) wrote: On Wednesday 04 January 2006 13:09, you wrote: On Wed, 4 Jan 2006, cobaco (aka Bart Cornelis) wrote: Package: base-files Version: 3.1.9 Severity: wishlist Tags: patch Adding the snippet below to /etc/profile modularizes /etc/profile so packages can drop snippets they want to add into an /etc/profile.d dir and have them picket up. No, not again. please use the wontfix tag instead of closing, this seems to be a textbook case of what the tag is for (and would avoid the whole 'again' frustration'). Sorry, but I have never been a big fan of the wontfix tag. Either a bug is a bug and should be fixed, or it is not and should be closed. There is no excuse for not reading the documentation. Please read /usr/share/doc/base-files/FAQ. had missed this, reading now ... as I'll explain below I don't feel it addresses the reason I want this: Q. Why does Debian not have a profile.d directory, like other distributions? A. Because no Debian package needs it. Debian policy says: A program must not depend on environment variables to get reasonable defaults. This policy has been very successful so far. If the default install had a profile.d, people might think it's ok to use it for a Debian package, when in fact policy does not support such thing. There's other reason's then setting environment variables _needed_ by a program to run to want a profile.d directory. For example adding some piece of management infrastructure for the admin, which is wat desktop-profiles does: essentially I need to run the profile activation script when logging in with 'ssh -X' (as the Xsession.d scripts then don't get run that way). That script parses configuration files, and based on the settings in them sets up the admin-controlled configuration sets to be used (which might differ according to usergroup, or any other testable condition) by the graphical apps of the various desktops. Programs will work just fine when those sets aren't loaded, they just won't be using the settings the administrator wants them to use (which might necessitate the user duplicating eacht setting the admin made, or might allow the user to avoid a mandatory setting). More generally there's the point of CDD's (desktop-profiles came out of that corner), the whole idea of which is to have a standard Debian, but configured to suit a specific target group/goal/situation. The only way to do this _inside_ of Debian is for packages to allow other packages to add bits of configuration (essentially the configuration package becomes the admin doing the initial setup). The other option is to fork each package needing configuration with all the extra work and effort that ncessitates. As the above (hopefully) makes clear there's currently at least 1 Debian package which _does_ need it, and with the growing number of CDD's there's bound to be more sooner or later. You are welcome to propose a policy change mandating the profile.d thing. Until then, I consider the profile.d thing as something harmful, as it would open a can of worms. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
