[opensuse-packaging] non-conffile-in-etc /etc/bash_completion.d
dkms.noarch: W: non-conffile-in-etc /etc/bash_completion.d/dkms A non-executable file in your package is being installed in /etc, but is not a configuration file. All non-executable files in /etc should be configuration files. Mark the file as %config in the spec file. Well, this file has no reason to be executable and it is in any case not a config file which is supposed to be edited by user. I see that at least one package installs completion under /usr/share/bash-completion/completions/; is it new place or package error? TIA -andrey -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 12/03/2012 07:34 PM, Andrey Borzenkov wrote: > dkms.noarch: W: non-conffile-in-etc /etc/bash_completion.d/dkms > A non-executable file in your package is being installed in /etc, but is not a > configuration file. All non-executable files in /etc should be configuration > files. Mark the file as %config in the spec file. 1) This would be a fix for rpmlint, which the maintainer (Dirk) is usually happy to take. > Well, this file has no reason to be executable and it is in any case > not a config file which is supposed to be edited by user. I see that at > least one package installs completion > under /usr/share/bash-completion/completions/; is it new place or > package error? At least this deviates from the majority of packages, does someone know if bash looks at this directory too? If so, the best approach would be to not do 1) but fix all other packages instead. -- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)
Le mardi 04 décembre 2012, à 12:59 +0100, Sascha Peilicke a écrit :
On 12/03/2012 07:34 PM, Andrey Borzenkov wrote:
Well, this file has no reason to be executable and it is in any case not a config file which is supposed to be edited by user. I see that at least one package installs completion under /usr/share/bash-completion/completions/; is it new place or package error? At least this deviates from the majority of packages, does someone know if bash looks at this directory too? If so, the best approach would be to not do 1) but fix all other packages instead.
/usr/share/bash-completion/ comes from the bash-completion package. I would think it's not expected to install files there, as this will likely only work when bash-completion is installed. But that's just a guess :-) Cheers, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 12/04/2012 01:14 PM, Vincent Untz wrote:
Le mardi 04 décembre 2012, à 12:59 +0100, Sascha Peilicke a écrit :
On 12/03/2012 07:34 PM, Andrey Borzenkov wrote:
Well, this file has no reason to be executable and it is in any case not a config file which is supposed to be edited by user. I see that at least one package installs completion under /usr/share/bash-completion/completions/; is it new place or package error? At least this deviates from the majority of packages, does someone know if bash looks at this directory too? If so, the best approach would be to not do 1) but fix all other packages instead.
/usr/share/bash-completion/ comes from the bash-completion package. I would think it's not expected to install files there, as this will likely only work when bash-completion is installed. That raises the question if bash completion works without bash-completion? I'm not using bash, so I'd be curious.
But that's just a guess :-) -- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)
Hi, On Tue, 4 Dec 2012, Sascha Peilicke wrote:
On 12/04/2012 01:14 PM, Vincent Untz wrote:
Le mardi 04 décembre 2012, à 12:59 +0100, Sascha Peilicke a écrit :
On 12/03/2012 07:34 PM, Andrey Borzenkov wrote:
Well, this file has no reason to be executable and it is in any case not a config file which is supposed to be edited by user. I see that at least one package installs completion under /usr/share/bash-completion/completions/; is it new place or package error? At least this deviates from the majority of packages, does someone know if bash looks at this directory too? If so, the best approach would be to not do 1) but fix all other packages instead.
/usr/share/bash-completion/ comes from the bash-completion package. I would think it's not expected to install files there, as this will likely only work when bash-completion is installed. That raises the question if bash completion works without bash-completion? I'm not using bash, so I'd be curious.
I does, yes. The bash-completion package provides more (and slower) completions than the standard set. Ciao, Michael.
Hello, @Werner: any thoughts/comments on this? Am Dienstag, 4. Dezember 2012 schrieb Vincent Untz:
Le mardi 04 décembre 2012, à 12:59 +0100, Sascha Peilicke a écrit :
On 12/03/2012 07:34 PM, Andrey Borzenkov wrote:
Well, this file has no reason to be executable and it is in any case not a config file which is supposed to be edited by user.
"Not supposed to be edited by user" also means it shouldn't live in /etc ;-) Nevertheless, /etc/bash_completion.d/ is currently the best (or should I say least-bad?) choice you have.
I see that at least one package installs completion under /usr/share/bash-completion/completions/; is it new place or package error?
At least this deviates from the majority of packages, does someone know if bash looks at this directory too? If so, the best approach would be to not do 1) but fix all other packages instead.
/usr/share/bash-completion/ comes from the bash-completion package. I would think it's not expected to install files there, as this will likely only work when bash-completion is installed.
Exactly, /usr/share/bash-completion/ is not really an option. I'm afraid the problem is slightly[tm] bigger than you might think - we have /etc/profile.d/ (read when a _login shell_ is started) which works for setting environment variables, but fails for things like completion that must be read whenever a new (non-login) shell is started. See http://lists.opensuse.org/opensuse-factory/2012-07/msg00233.html and http://lists.opensuse.org/opensuse-factory/2012-07/msg00234.html for details (BTW: /etc/bash.bashrc already contains workarounds for /etc/bash_completion.d/ and various files in /etc/profile.d - which doesn't match the idea of a "just drop a file" directory). The correct solution would be to have a) /etc/profile.d/ - setting up environment variables, read for login shells (environment variables are exported to child processes - no need to read /etc/profile.d/* again) b) /etc/bash.d/ [1] - files that are read whenever a bash is started, basically a modular bashrc for setting up aliases, functions etc. Maybe the files from /etc/bash_completion.d could also be moved here [2]. c) /usr/share/profile.d/ and /usr/share/bash.d/ [3] as counterparts to the directories in /etc. The /usr/ directories should be used for packaged files which typically won't be edited by a user. Ideally we would have a check for files with the same name in /etc/, which would skip reading the /usr files (similar to the way systemd uses) [4] Afterwards, we could - "cleanup" /etc/profile.d/ - some of the files should live in /etc/bash.d - drop various ". $foo" workarounds from /etc/bash.bashrc What do you thing about this proposal? Regards, Christian Boltz [1] same for other shells on the long term [2] technically, you can do it the other way round and put stuff you want to read at each bash startup in /etc/bash_completion.d/ - but the directory name implies it's only meant for completion. [3] Directory names are only proposals, feel free to propose better ones [4] untested: for file in /usr/share/bash.d/* ; do test -f /etc/bash.d/$(basename $file) && continue . $file done --
Man könnte statt bisher zwei nun vier Files anlegen. [...] Kurz gesagt: Das ist zu kompliziert. Ich habe gehofft, dass du das sagst. [Ratti und > Christian Boltz in fontlinge-devel]
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tue, Dec 04, 2012 at 08:50:05PM +0100, Christian Boltz wrote:
Hello,
@Werner: any thoughts/comments on this?
Am Dienstag, 4. Dezember 2012 schrieb Vincent Untz:
Le mardi 04 décembre 2012, à 12:59 +0100, Sascha Peilicke a écrit :
On 12/03/2012 07:34 PM, Andrey Borzenkov wrote:
Well, this file has no reason to be executable and it is in any case not a config file which is supposed to be edited by user.
"Not supposed to be edited by user" also means it shouldn't live in /etc ;-)
Nevertheless, /etc/bash_completion.d/ is currently the best (or should I say least-bad?) choice you have.
I see that at least one package installs completion under /usr/share/bash-completion/completions/; is it new place or package error?
At least this deviates from the majority of packages, does someone know if bash looks at this directory too? If so, the best approach would be to not do 1) but fix all other packages instead.
/usr/share/bash-completion/ comes from the bash-completion package. I would think it's not expected to install files there, as this will likely only work when bash-completion is installed.
Exactly, /usr/share/bash-completion/ is not really an option.
I'm afraid the problem is slightly[tm] bigger than you might think - we have /etc/profile.d/ (read when a _login shell_ is started) which works for setting environment variables, but fails for things like completion that must be read whenever a new (non-login) shell is started.
See http://lists.opensuse.org/opensuse-factory/2012-07/msg00233.html and http://lists.opensuse.org/opensuse-factory/2012-07/msg00234.html for details (BTW: /etc/bash.bashrc already contains workarounds for /etc/bash_completion.d/ and various files in /etc/profile.d - which doesn't match the idea of a "just drop a file" directory).
The correct solution would be to have a) /etc/profile.d/ - setting up environment variables, read for login shells (environment variables are exported to child processes - no need to read /etc/profile.d/* again) b) /etc/bash.d/ [1] - files that are read whenever a bash is started, basically a modular bashrc for setting up aliases, functions etc. Maybe the files from /etc/bash_completion.d could also be moved here [2]. c) /usr/share/profile.d/ and /usr/share/bash.d/ [3] as counterparts to the directories in /etc. The /usr/ directories should be used for packaged files which typically won't be edited by a user. Ideally we would have a check for files with the same name in /etc/, which would skip reading the /usr files (similar to the way systemd uses) [4]
Afterwards, we could - "cleanup" /etc/profile.d/ - some of the files should live in /etc/bash.d - drop various ". $foo" workarounds from /etc/bash.bashrc
What do you thing about this proposal?
Hmmm ... the /etc/bash.bashrc is also for other bourne shells around therefore I'd like to know why now we want to move all parts below /etc to /usr/share ... those files are potenial editable and for me those files are (potential) configuration files.
[1] same for other shells on the long term
[2] technically, you can do it the other way round and put stuff you want to read at each bash startup in /etc/bash_completion.d/ - but the directory name implies it's only meant for completion.
[3] Directory names are only proposals, feel free to propose better ones
[4] untested:
for file in /usr/share/bash.d/* ; do test -f /etc/bash.d/$(basename $file) && continue
/etc/bash.d/${file##*/}
. $file done
This one I like ... nevertheless this requires a README below /usr/share/sh.d/ or /usr/share/profile.d/ to point out to copy a file from this directory to /etc/sh.d/ or /etc/profile.d/ Please note that the files should show the correct suffix that is *.sh for all bourne shells *.ash for the ash *.bash for the bash *.dash for the dash *.ksh for the ksh *.csh for all csh shells *.tcsh for the tcsh this would help a lot. Most times this will be *.sh and *.csh but for special cases like shell specific languages the other suffixes should be used. Also for enviroment only the profile.d trees should be used to do this only once for a login shell, e.g. the shell used for an X session. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, Am Freitag, 7. Dezember 2012 schrieb Dr. Werner Fink:
On Tue, Dec 04, 2012 at 08:50:05PM +0100, Christian Boltz wrote:
we have /etc/profile.d/ (read when a _login shell_ is started) which works for setting environment variables, but fails for things like completion that must be read whenever a new (non-login) shell is started.
The correct solution would be to have a) /etc/profile.d/ - setting up environment variables, read for login shells
b) /etc/bash.d/ [1] - files that are read whenever a bash is started.
c) /usr/share/profile.d/ and /usr/share/bash.d/ [3] as counterparts to the directories in /etc.
Afterwards, we could - "cleanup" /etc/profile.d/ - some of the files should live in /etc/bash.d - drop various ". $foo" workarounds from /etc/bash.bashrc
What do you thing about this proposal?
Hmmm ... the /etc/bash.bashrc is also for other bourne shells around therefore I'd like to know why now we want to move all parts below /etc to /usr/share ... those files are potenial editable and for me those files are (potential) configuration files.
I know that those files are potential editable, but OTOH most users will never edit them. That's why I proposed to move them to /usr with the option to override them in /etc. The reason is to keep default/unchanged stuff out of /etc so that the really changed/overridden files are better visible. That's one of the concepts of systemd that I like and that works quite well ;-) That said, the most important thing is to separate profile.d and sh.d. Moving to /usr/ is "just" additional cleanup - but we could get it nearly "for free" when moving around files between profile.d and sh.d.
[3] Directory names are only proposals, feel free to propose better ones> [4] untested: for file in /usr/share/bash.d/* ; do test -f /etc/bash.d/$(basename $file) && continue
/etc/bash.d/${file##*/}
Does this work for all shells or only for bash? (Besides that, the code was just a first, untested proposal.)
. $file done
This one I like ... nevertheless this requires a README below /usr/share/sh.d/ or /usr/share/profile.d/ to point out to copy a file from this directory to /etc/sh.d/ or /etc/profile.d/
Yes, documentation is always a good idea ;-)
Please note that the files should show the correct suffix that is
*.sh for all bourne shells *.ash for the ash *.bash for the bash *.dash for the dash *.ksh for the ksh *.csh for all csh shells *.tcsh for the tcsh
this would help a lot. Most times this will be *.sh and *.csh but for special cases like shell specific languages the other suffixes should be used.
Indeed, using suffixes is a good method. (This also means one directory ("sh.d") is enough - no need for "bash.d" etc. as I initially proposed.) Do you have a good idea how to name the directories in /usr? You mentioned /usr/share/profile.d and /usr/share/sh.d which is not too bad - but IMHO both should have a common parent directory. Maybe /usr/share/shells/profile.d and /usr/share/shells/sh.d?
Also for enviroment only the profile.d trees should be used to do this only once for a login shell, e.g. the shell used for an X session.
Yes, of course. The missing separation between profile.d and sh.d is basically a bug, and getting it fixed was the initial reason for my proposal. How can we continue? AFAIK you have a very good overview over all shells, so you are probably the best person to lead and/or implement this ;-) If you want, I can help on the bash side. Be warned that I don't know anything about other shells. This also means I don't want to break tcsh or ksh ;-) and will leave this up to you or another volunteer. First technical question: Does any shell directly read /etc/profile.d/ or do they all read it indirectly via /etc/profile and /etc/*shrc? Regards, Christian Boltz --
Ich versuchs mal so zu sagen: Ich versuche gerade, dich laaaangsam ins kalte Wasser zu schubsen. ich mag kein kaltes Wasser, las uns die weiteren Tests nach Playa de Santiago verlegen, da dürfte das Wasser jetzt ca. 20° C haben. [> Ratti und Gerald Goebel in fontlinge-devel] -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (6)
-
Andrey Borzenkov
-
Christian Boltz
-
Dr. Werner Fink
-
Michael Matz
-
Sascha Peilicke
-
Vincent Untz