Bug#348336: improve section on shared config files
On Sunday 29 January 2006 02:36, Santiago Vila wrote: +Sometimes two or more packgages need to be able to modify the +same configuration file. One such case is were related packages +share a configuration file (e.g. bash and other bourn compatible +shells share /etc/profile). You are implicitly saying that there are packages that need to modify /etc/profile. The reason that /etc/profile is in base-files AFAICT is because it's shared between all bourne-compatible shells. The above claims that /etc/profile is an example of a shared configuration file. How is this inaccurate? The actual shell packages don't do anything with /etc/profile at the moment, so don't need a mechanism to adapt it. On the other hand there's currently at least 5 packages[1] that have a blurb in their README saying something to the effect of add this bit to /etc/profile for the package to do everything it promises to. No surprise to me that all of those happen to fit the single extra use case that this proposal documents. - So yes, there's a _demonstrated_ need for configuration packages to be able to modify /etc/profile The way I read policy 9.9, packages should not need to modify /etc/profile to be useful. Policy 9.9. talks about programs depending on environment variables to work and explicitly forbids (with a must clause) using /etc/profile to set up those environment variables. None of which has anything to do with the use case of configuration packages, which most empatically do _not_ modify anything _needed_ by a program to work. Programs will work just fine without the more specific configuration provided by the configuration package, they just won't be set up to address the needs of the more narrowly defined target that the configuration package is aimed at. Therefore I object to this proposal in its current form. Note that this proposal does not open op /etc/profile (or any other configuration file) for random use by any package, especially use cases that are explicitly forbidden by policy, it merely opens it up for configuration packages as used by CDD's. [1] desktop-profiles, user-de, user-es, user-euro-es, and sysprofile are the ones I know of -- 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) pgpFdrl6LKUzY.pgp Description: PGP signature
Bug#348336: improve section on shared config files
On Mon, 30 Jan 2006, cobaco (aka Bart Cornelis) wrote: On Sunday 29 January 2006 02:36, Santiago Vila wrote: +Sometimes two or more packgages need to be able to modify the +same configuration file. One such case is were related packages +share a configuration file (e.g. bash and other bourn compatible +shells share /etc/profile). You are implicitly saying that there are packages that need to modify /etc/profile. The reason that /etc/profile is in base-files AFAICT is because it's shared between all bourne-compatible shells. The above claims that /etc/profile is an example of a shared configuration file. How is this inaccurate? No, the above claims more than you say it claims. You are putting /etc/profile as an example of a) file which is shared as a configuration file and b) file which two or more packages need to be able to modify. I object to b) being in policy. The file /etc/profile is not a file which two or more packages need to be able to modify. [...] On the other hand there's currently at least 5 packages[1] that have a blurb in their README saying something to the effect of add this bit to /etc/profile for the package to do everything it promises to. No surprise to me that all of those happen to fit the single extra use case that this proposal documents. - So yes, there's a _demonstrated_ need for configuration packages to be able to modify /etc/profile Not at all. Just because some packages do something does not mean they need to do it, or that they need to do something the way they do it. For example, let't take the user-es package, which you always mention as an example of package that needs profile.d. What does such package do? It has a README saying the user to add this line to /etc/profile: if [ -f /etc/language-es ]; then source /etc/language-es; fi The file /etc/language-es sets lot of environment variables. However, /etc/profile is the wrong place to do that, as it does not work in every shell. The file /etc/environment would be much more appropriate. So, just because some packages tell the user modify /etc/profile does not mean they need to modify /etc/profile. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348336: improve section on shared config files
On Monday 30 January 2006 13:17, Santiago Vila wrote: On Mon, 30 Jan 2006, cobaco (aka Bart Cornelis) wrote: On Sunday 29 January 2006 02:36, Santiago Vila wrote: I object to b) being in policy. The file /etc/profile is not a file which two or more packages need to be able to modify. [...] On the other hand there's currently at least 5 packages[1] that have a blurb in their README saying something to the effect of add this bit to /etc/profile for the package to do everything it promises to. Not at all. Just because some packages do something does not mean they need to do it, or that they need to do something the way they do it. For example, let't take the user-es package, which you always mention as an example of package that needs profile.d. What does such package do? It has a README saying the user to add this line to /etc/profile: if [ -f /etc/language-es ]; then source /etc/language-es; fi The file /etc/language-es sets lot of environment variables. However, /etc/profile is the wrong place to do that, as it does not work in every shell. The file /etc/environment would be much more appropriate. except that one the variables is set conditionally, which AFAIK you can't do in /etc/environment (Note: otherwise I agree that in the case of user-es /etc/environment is a better place to do this, though the current approach certainly works for bourne-type shells) Though that doesn't stop the need for a modularization/adaptation mechanism, it just moves it from /etc/profiles to /etc/environment. So, just because some packages tell the user modify /etc/profile does not mean they need to modify /etc/profile. As far as I know there is no cross-shell way to conditionally set environment variables which both desktop-profiles and user-es need (the former more so then the latter). That only leaves the option to do it piecemal, which needs adaption of /etc/profile (and similar files for other shells). If you have a better way of meeting this particular need I'd love to hear it. Also note that the (e.g. bash and other bourn compatible shells share /etc/profile)-bit in the proposed patch can easily be removed it that's what realy bugs you, that wouldn't change the proposal in any meaningfull way. -- cobaco (aka Bart Cornelis): Coördinator Belgisch Skolelinux team Coördinator Nederlandse Skolelinux vertaling pgpz2d1bms2gw.pgp Description: PGP signature
Bug#348336: improve section on shared config files
+Sometimes two or more packgages need to be able to modify the +same configuration file. One such case is were related packages +share a configuration file (e.g. bash and other bourn compatible +shells share /etc/profile). You are implicitly saying that there are packages that need to modify /etc/profile. The way I read policy 9.9, packages should not need to modify /etc/profile to be useful. Therefore I object to this proposal in its current form. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
