Re: Question about profile.d scripts definition in Spec file
On Tue, Aug 4, 2015, at 01:38 PM, Michael Schwendt wrote: Either %config or %config(noreplace) can cause problems during update. Neither one is completely safe with regard to breaking a program at runtime. It can be necessary to switch from %config(noreplace) to %config, or vice versa, in updates. FWIW rpm-ostree (really ostree) consistently uses the equivalent of %config(noreplace) always for everything in /etc, regardless of what the input RPM says. I think global predictability and consistency here is superior to per-package choice. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Question about profile.d scripts definition in Spec file
On Wed, 05 Aug 2015 06:37:41 -0400, Colin Walters wrote: On Tue, Aug 4, 2015, at 01:38 PM, Michael Schwendt wrote: Either %config or %config(noreplace) can cause problems during update. Neither one is completely safe with regard to breaking a program at runtime. It can be necessary to switch from %config(noreplace) to %config, or vice versa, in updates. FWIW rpm-ostree (really ostree) consistently uses the equivalent of %config(noreplace) always for everything in /etc, regardless of what the input RPM says. I think global predictability and consistency here is superior to per-package choice. MUST: Admin must painstakingly review and handle all .rpmnew/.rpmsave files, which are created when installing an update. Aiming for consistency, I agree with that. Predictability? Nah. Both %config and %config(noreplace) bear risks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Question about profile.d scripts definition in Spec file
On 04.08.2015 19:38, Michael Schwendt wrote: On Mon, 3 Aug 2015 22:16:39 +0200, Marcin Haba wrote: Btw, rpmlint does not override Fedora's packaging guidelines: https://fedoraproject.org/wiki/Packaging:Guidelines#Configuration_files Not override, but good when rpmlint follows on packaging guidelines as much as possible and reasonable. You could open a RFE in rpmlint upstream tracker. Or try to get Fedora's rpmlint to point at the packaging guidelines section instead of mentioning %config directly. Thanks for the tip. Your idea seems OK, however I am not sure if I really want go in this direction. Best regards. Marcin Haba signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Question about profile.d scripts definition in Spec file
On Mon, 3 Aug 2015 22:16:39 +0200, Marcin Haba wrote: If not marking the files below /etc as %config, any update would overwrite them. Marking them as %config signals RPM to handle the update more gracefully. Yes, true. It will handle the update more gracefully, however it does not protect from overwrite a file. That's why the '(noreplace)' bit exists for the %config attribute. So, maybe better for profile.d to use %config(noreplace)? Either %config or %config(noreplace) can cause problems during update. Neither one is completely safe with regard to breaking a program at runtime. It can be necessary to switch from %config(noreplace) to %config, or vice versa, in updates. For example, if a config file changed from INI-style to XML, it would be a major problem if not replacing it during an update. Same for profile.d scripts. If those scripts in an update do much more than the older and modified installed files, the update may not work anymore when not replacing the old scripts. Let's not go in circles. Marking files below /etc as configuration files can be a good thing, but is not without risk in all cases. Btw, rpmlint does not override Fedora's packaging guidelines: https://fedoraproject.org/wiki/Packaging:Guidelines#Configuration_files Not override, but good when rpmlint follows on packaging guidelines as much as possible and reasonable. You could open a RFE in rpmlint upstream tracker. Or try to get Fedora's rpmlint to point at the packaging guidelines section instead of mentioning %config directly. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Question about profile.d scripts definition in Spec file
On Mon, 3 Aug 2015 09:09:43 +0200, Marcin Haba wrote: I trying to express my opinion about my understanding 'configuration files' meaning. Of course. In my opinion that this type of files can be classified as pre-defined settings files, not configuration files. In any case, it looks that we have different understanding configuration files and it causes cross over our opinions. So, a configuration file, which contains constants or is not changed for a very long time, becomes a settings file? And a settings file that gets modified by an admin to customise the defaults becomes a configuration file? There are more names one could use for such a file, such as preferences file, defaults file, initialization file, setup file. I don't think there is not even a subtle difference. It depends on a definition of how such a file is supposed to be used. For some sets of files there is a specific order in which they are read. Instructions on which file to modify and which file not to touch. Without such specific instructions, all that matters is whether a change to the file influences the program's runtime configuration. I think also that better could be set the environment variables values in /etc/defaults/ and use these values by shell scripts instead using hard-coded values in shell scripts. Files in /etc/default are configuration files, too, and are to be marked as such in RPM packages. Coming back to profile.d sample, when somebody try to modify profile.d file marked as %config [not %config(noreplace)] then after upgrade package with new profile.d file version, the file will be overwritten and user will lose introduced changes. It seems that all this situation uncovers bigger problem :-) Which problem do you see? If _not_ marked as configuration file, the file will be overwritten by an update, too. = Any changes are lost and may break runtime configuration until restoring the modification of the file. If marked as %config or %config(noreplace), RPM will create .rpmsave or .rpmnew files the admin/user will need to review. Where such files are stored, doesn't matter. /etc/default/ is not free of problems either. Imagine renamed env vars that would be incompatible after a version upgrade of a package. Migrating config file changes is a basic system maintenance task. Yes, rpmlint cannot get it 100% right, but it can report potential executable files more accurate. It could only _try to_ and would print even more guesses and false positives. Such as checking for shebang values in files lacking execute permission bits. And still it could be intentional that the files are not executable by default (- examples, templates, stubs). If something can offload person, that for example do review request, from manual checking content of files, why not use it? Wishful thinking. A tool like rpmlint will never develop a better understanding for an RPM package than the person, who created that package and will maintain it. Reviewing packages is not rocket science. In most cases a just do it mentality during package review phase would be extremely helpful instead of trying to complicate matters. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Question about profile.d scripts definition in Spec file
On 02.08.2015 23:15, Michael Schwendt wrote: On Sun, 2 Aug 2015 16:29:06 +0200, Marcin Haba wrote: A) if a shell script can be treated as configuration file? Certainly. It's a cheap way to set a program's runtime configuration instead of implementing a full config file loader/parser. My image of configuration files is that they are files for read/write purpose by design, because they enables _configure_ something (application, service, single program, script...whatever). If they are dedicated only for reading then from my point of view they lose configuration meaning (something like WORM storage ;-) ). Why would you say that? Hello Michael, I trying to express my opinion about my understanding 'configuration files' meaning. There are read-only config files to set the system-wide default for everyone. The program reads them first before looking for user's local config files to override the defaults. The program would never write the system-wide file file in /etc, but at most the user's local file. In my opinion that this type of files can be classified as pre-defined settings files, not configuration files. In any case, it looks that we have different understanding configuration files and it causes cross over our opinions. I think also that better could be set the environment variables values in /etc/defaults/ and use these values by shell scripts instead using hard-coded values in shell scripts. Coming back to profile.d sample, when somebody try to modify profile.d file marked as %config [not %config(noreplace)] then after upgrade package with new profile.d file version, the file will be overwritten and user will lose introduced changes. It seems that all this situation uncovers bigger problem :-) And in general, whether a program can write its own config files is purely a question of design. Clearly, over the years there have been programs that only read config files somebody [or some tool] can create. /etc/bashrc, /etc/profile are examples of %config files where the file format is shell language code to be interpreted by a shell. cut However I believe that exist some tools or libraries that can do this content analyze for rpmlint. What would be the benefit? rpmlint cannot get it 100% right anyway. There could be corner-cases, where a config file gets executed instead of being sourced like a shell include file. Yes, rpmlint cannot get it 100% right, but it can report potential executable files more accurate. If something can offload person, that for example do review request, from manual checking content of files, why not use it? It's some sort of white-list to assume that files in /etc meant to be executed (such as initscripts related files) are not configuration files in any way. Admin may decide to edit such executables nevertheless (for reasons unknown), but the next update would overwrite the changes. Good to know that mentioned white-list exists. Could you indicate me where can I find this white-list? With some sort of white-list I mean the simplification -- the simplified assumption -- that files with execute permission are believed to be executables and not configuration files. And vice versa. Real configuration files being marked executable are believed to be mistakes. OK. Thanks for clarify. Best regards. Marcin Haba signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Question about profile.d scripts definition in Spec file
On 02.08.2015 23:58, Jonathan Underwood wrote: On 2 August 2015 at 22:57, Jonathan Underwood jonathan.underw...@gmail.com wrote: On 2 August 2015 at 15:29, Marcin Haba marcin.h...@bacula.pl wrote: My image of configuration files is that they are files for read/write purpose by design, because they enables _configure_ something (application, service, single program, script...whatever). If they are dedicated only for reading then from my point of view they lose configuration meaning (something like WORM storage ;-) ). This is probably an argument for having shell configuration fragments packaged under /usr/lib/bash/profile.d rather than /etc/profile.d. .. or /usr/share/bash/profile.d, perhaps. Hello Jonathan, That is also good idea, I think. Thanks. Best regards. Marcin Haba signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Question about profile.d scripts definition in Spec file
On Mon, 3 Aug 2015 20:22:43 +0200, Reindl Harald wrote: Am 03.08.2015 um 20:15 schrieb Michael Schwendt: And %config(noreplace) is not guaranteed to be the better choice anyway. Who guarantees that the updated software still works flawlessly with old config files and new config files created as .rpmnew? Testing for all such changes is not a trivial task well, the point is: you can never know if a future version will work with the old configs, *but* * as long the config fiel is untouched it will be overwritten and in sync with the package due updates Same when marking as %config. Same for all ordinary files. * you have at least the .rpmnew file with the current defaults And the not replaced config file may not survive a reboot or a restart of the service already due to incompatibilities (as the worst case scenario) so %config(noreplace) is not only he better choice, it's the only one except ship no config at all but only a config.readme and force the admin to copy that to the right location (in case of network aware services i would honestly prefer thex won't start at all without at least one look at the config from the user) The thread was about rpmlint warning about files in /etc not being marked as %config: W: non-conffile-in-etc /etc/profile.d/ossim.sh Whether to mark them %config(noreplace) instead (to follow guidelines) is another question. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Question about profile.d scripts definition in Spec file
Am 03.08.2015 um 20:38 schrieb Michael Schwendt: On Mon, 3 Aug 2015 20:22:43 +0200, Reindl Harald wrote: Am 03.08.2015 um 20:15 schrieb Michael Schwendt: And %config(noreplace) is not guaranteed to be the better choice anyway. Who guarantees that the updated software still works flawlessly with old config files and new config files created as .rpmnew? Testing for all such changes is not a trivial task well, the point is: you can never know if a future version will work with the old configs, *but* * as long the config fiel is untouched it will be overwritten and in sync with the package due updates Same when marking as %config. Same for all ordinary files. yes, but not relevant * you have at least the .rpmnew file with the current defaults And the not replaced config file may not survive a reboot or a restart of the service already due to incompatibilities (as the worst case scenario) so %config(noreplace) is not only he better choice, it's the only one except ship no config at all but only a config.readme and force the admin to copy that to the right location (in case of network aware services i would honestly prefer thex won't start at all without at least one look at the config from the user) The thread was about rpmlint warning about files in /etc not being marked as %config: W: non-conffile-in-etc /etc/profile.d/ossim.sh the question is simply answered: as sysadmin i expect *anything* below /etc as configuration intended to be changed local and not overwritten by regular package updates anything which is not intended to for local changes belongs to /usr Whether to mark them %config(noreplace) instead (to follow guidelines) is another question yes signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Question about profile.d scripts definition in Spec file
Am 03.08.2015 um 20:15 schrieb Michael Schwendt: And %config(noreplace) is not guaranteed to be the better choice anyway. Who guarantees that the updated software still works flawlessly with old config files and new config files created as .rpmnew? Testing for all such changes is not a trivial task well, the point is: you can never know if a future version will work with the old configs, *but* * as long the config fiel is untouched it will be overwritten and in sync with the package due updates * you have at least the .rpmnew file with the current defaults so %config(noreplace) is not only he better choice, it's the only one except ship no config at all but only a config.readme and force the admin to copy that to the right location (in case of network aware services i would honestly prefer thex won't start at all without at least one look at the config from the user) signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Question about profile.d scripts definition in Spec file
On Mon, 3 Aug 2015 20:48:53 +0200, Reindl Harald wrote: * as long the config fiel is untouched it will be overwritten and in sync with the package due updates Same when marking as %config. Same for all ordinary files. yes, but not relevant Really? Ordinary files in /etc don't meet your expectations (see below). They could be overwritten any time during an upgrade. Just like files marked as %config. Hell could break lose, if /etc/init.d/functions were marked as %config(noreplace) and an update would only create an .rpmnew copy of the new file. Marking files as %config(noreplace) is a trade-off. Whether to mark a file as such is to be decided on a case-by-case basis. as sysadmin i expect *anything* below /etc as configuration intended to be changed local and not overwritten by regular package updates anything which is not intended to for local changes belongs to /usr Sure. That may be the future. However, not everything in /etc is marked as a configuration file yet. Simply claiming that files in /etc/profile.d/ are not configuration files to begin complicates matters too much. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Question about profile.d scripts definition in Spec file
Hello Michael, W dniu 03.08.2015 o 13:09, Michael Schwendt pisze: In my opinion that this type of files can be classified as pre-defined settings files, not configuration files. In any case, it looks that we have different understanding configuration files and it causes cross over our opinions. So, a configuration file, which contains constants or is not changed for a very long time, becomes a settings file? And a settings file that gets modified by an admin to customise the defaults becomes a configuration file? I did not say that. The only one message that I am trying to say in this point is: configuration files for me should be designed to configure/modify by administrator or directly by application. If some files are designed only for reading values like auto-generated files or mentioned by you pre-defined variables or just scripts, I do not treat them in configuration files aspect at all. And better when they are marked special clause in comment. As long the types calling is not standardized in a official common specification and it is used at the discretion, as long we can talk about it. As I wrote in one from my first mail in this thread: I guess that it is subject to longer discussion and not here (off-topic). There are more names one could use for such a file, such as preferences file, defaults file, initialization file, setup file. I don't think there is not even a subtle difference. It depends on a definition of how such a file is supposed to be used. Indeed. Unfortunately we do not have any common definition. I think also that better could be set the environment variables values in /etc/defaults/ and use these values by shell scripts instead using hard-coded values in shell scripts. Files in /etc/default are configuration files, too, and are to be marked as such in RPM packages. Coming back to profile.d sample, when somebody try to modify profile.d file marked as %config [not %config(noreplace)] then after upgrade package with new profile.d file version, the file will be overwritten and user will lose introduced changes. It seems that all this situation uncovers bigger problem :-) Which problem do you see? I am seeing problem overwriting files if somebody hastily use %config on script instead %config(noreplace) only because rpmlint returns warning on package. Then it can result unexpected overwriting this file during update the package. If this overrwrite action will cause that for example offline blog application nothing big is happening. If it will cause move offline large 24/7 service, it can result troubles. If marked as %config or %config(noreplace), RPM will create .rpmsave or .rpmnew files the admin/user will need to review. Yes, but for some services triggering offline can be more painful than configuration lost. On files always can do backup, on services downtime cannot. Yes, rpmlint cannot get it 100% right, but it can report potential executable files more accurate. It could only _try to_ and would print even more guesses and false positives. Such as checking for shebang values in files lacking execute permission bits. And still it could be intentional that the files are not executable by default (- examples, templates, stubs). Yes, I did not think about this cases. You are right. If something can offload person, that for example do review request, from manual checking content of files, why not use it? Wishful thinking. A tool like rpmlint will never develop a better understanding for an RPM package than the person, who created that package and will maintain it. Reviewing packages is not rocket science. In most cases a just do it mentality during package review phase would be extremely helpful instead of trying to complicate matters. Thanks for your opinions and valuable discussion. Best regards. Marcin Haba signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Question about profile.d scripts definition in Spec file
On Mon, 3 Aug 2015 19:02:26 +0200, Marcin Haba wrote: The only one message that I am trying to say in this point is: configuration files for me should be designed to configure/modify by administrator or directly by application. A moot point, too. First of all, if not installing prebuilt RPM packages, usually it's the admin who compiles and installs the software from sources. That involves a first configuration step already. The admin makes choices where to install (e.g. /usr vs. /usr/local), which features to enable, and possibly influences other configuration defaults, too. After installation, the admin would edit available config file as necessary. When installing from a distributor's RPM package collection, some of those steps are handled by the package maintainer. Other steps are postponed. Again, the admin likely needs to review the prebuilt config files and apply modifications. Back to ossim-data: if [ -z $OSSIM_INSTALL_PREFIX ]; then export OSSIM_INSTALL_PREFIX=/usr fi if [ -z $OSSIM_PREFS_FILE ]; then export OSSIM_PREFS_FILE=$OSSIM_INSTALL_PREFIX/share/ossim/ossim_preferences fi The program could simply hardcode those paths at compile-time. What's the benefit of using env vars? Clearly it's the option to reconfigure the program at runtime. If not via extra command-line options when running the program, the user or the admin could point the program at different paths with modifications to these configuration files. During an update of the packages, the files would be reset to the distribution default and break the user's/admin's customisation. The package user will be annoyed, because /etc specifically is for configuration files. If the packager will not mark the files as configuration files, the admin will likely override those env vars elsewhere or abandon using the packages. If some files are designed only for reading values like auto-generated files or mentioned by you pre-defined variables or just scripts, I do not treat them in configuration files aspect at all. And better when they are marked special clause in comment. As long the types calling is not standardized in a official common specification and it is used at the discretion, as long we can talk about it. As I wrote in one from my first mail in this thread: I guess that it is subject to longer discussion and not here (off-topic). The alternative list is packaging@ for Fedora packaging related topics. I only would like to understand why you would not treat such files as configuration. That's the only motivation for my replies so far. ;-) Which problem do you see? I am seeing problem overwriting files if somebody hastily use %config on script instead %config(noreplace) only because rpmlint returns warning on package. Then it can result unexpected overwriting this file during update the package. How would that be different from not marking the same file %config? If not marking the files below /etc as %config, any update would overwrite them. Marking them as %config signals RPM to handle the update more gracefully. And %config(noreplace) is not guaranteed to be the better choice anyway. Who guarantees that the updated software still works flawlessly with old config files and new config files created as .rpmnew? Testing for all such changes is not a trivial task. If this overrwrite action will cause that for example offline blog application nothing big is happening. If it will cause move offline large 24/7 service, it can result troubles. As above, not marking them %config bears exactly the same risk. Plus, you lose the modifications because no backup files are created. Btw, rpmlint does not override Fedora's packaging guidelines: https://fedoraproject.org/wiki/Packaging:Guidelines#Configuration_files -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Question about profile.d scripts definition in Spec file
Hello Michael, On 03.08.2015 20:15, Michael Schwendt wrote: On Mon, 3 Aug 2015 19:02:26 +0200, Marcin Haba wrote: The only one message that I am trying to say in this point is: configuration files for me should be designed to configure/modify by administrator or directly by application. A moot point, too. It is my opinion, so it can seem to be a moot point :-) First of all, if not installing prebuilt RPM packages, usually it's the admin who compiles and installs the software from sources. That involves a first configuration step already. The admin makes choices where to install (e.g. /usr vs. /usr/local), which features to enable, and possibly influences other configuration defaults, too. After installation, the admin would edit available config file as necessary. Yes, true. It is normal administrator matter: use binary packages or compile something self. When installing from a distributor's RPM package collection, some of those steps are handled by the package maintainer. Other steps are postponed. Again, the admin likely needs to review the prebuilt config files and apply modifications. Yes, it is also normal. I am not sure why are you writing about it. If it is to text about configuration files modification by administrator or application I this sentence I did not mean neither compilation self nor binary packages way, but just general using configuration files independent on installation method. Very simple examples: - Modification by administrator a config file: # vi /etc/httpd/conf.d/my_favourite_website.conf [save config after modification] - Modification by application: # hostname home.lan Back to ossim-data: if [ -z $OSSIM_INSTALL_PREFIX ]; then export OSSIM_INSTALL_PREFIX=/usr fi if [ -z $OSSIM_PREFS_FILE ]; then export OSSIM_PREFS_FILE=$OSSIM_INSTALL_PREFIX/share/ossim/ossim_preferences fi The program could simply hardcode those paths at compile-time. What's the benefit of using env vars? Clearly it's the option to reconfigure the program at runtime. If not via extra command-line options when running the program, the user or the admin could point the program at different paths with modifications to these configuration files. During an update of the packages, the files would be reset to the distribution default and break the user's/admin's customisation. That is not good. The package user will be annoyed, because /etc specifically is for configuration files. If the packager will not mark the files as configuration files, the admin will likely override those env vars elsewhere or abandon using the packages. I would be annoyed either. If some files are designed only for reading values like auto-generated files or mentioned by you pre-defined variables or just scripts, I do not treat them in configuration files aspect at all. And better when they are marked special clause in comment. As long the types calling is not standardized in a official common specification and it is used at the discretion, as long we can talk about it. As I wrote in one from my first mail in this thread: I guess that it is subject to longer discussion and not here (off-topic). The alternative list is packaging@ for Fedora packaging related topics. I only would like to understand why you would not treat such files as configuration. That's the only motivation for my replies so far. ;-) That is nice :-) The reason is simple: from my point of view configuration files phrase does not refer its 'configuration' word to action configure something by my content but configure something by editing my content. The same way README files do not say read my name, but read my content...etc. :-) I am sorry if my explanation is unclear. My English is still on low level and sometimes I am not able to explain something. Specially this type of word game. Which problem do you see? I am seeing problem overwriting files if somebody hastily use %config on script instead %config(noreplace) only because rpmlint returns warning on package. Then it can result unexpected overwriting this file during update the package. How would that be different from not marking the same file %config? I do not claim that not using %config is better solution. Also from this reason I am here in this thread, because my main question was what can I do with the rpmlint warning about profile.d script definition in Spec. Up till know I learned that %config is more suitable for config.d scripts. If not marking the files below /etc as %config, any update would overwrite them. Marking them as %config signals RPM to handle the update more gracefully. Yes, true. It will handle the update more gracefully, however it does not protect from overwrite a file. And %config(noreplace) is not guaranteed to be the better choice anyway. Who guarantees that the updated software still works flawlessly with old config files and new config files created as .rpmnew? Testing
Re: Question about profile.d scripts definition in Spec file
On 08/02/2015 08:39 AM, Marcin Haba wrote: Hello, I am trying to make informal review following feature request: https://bugzilla.redhat.com/show_bug.cgi?id=1244353 One from warnings returned by rpmlint is: ossim-data.x86_64: W: non-conffile-in-etc /etc/profile.d/ossim.sh Because ossim.sh is not configuration file but shell script (as usual in profile.d/) I had a doubt about treating this warning. Well, I sense a misinterpretation of %config. In the context of the /etc file hierarchy %config means user-customizable, which means rpm/yum/dnf updates must not destroy any changes a user may have applied and should backup instead. So I asked on fedora-review IRC channel and there I received answer that this warning is acceptable. Well, it's a minor issue, but it definitely is arguable. In the bugzilla task I received answer that for the ossim.sh file should be used %config macro. My question is: what is valid answer for this case? My recommendation is to use %config. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Question about profile.d scripts definition in Spec file
Hello, I am trying to make informal review following feature request: https://bugzilla.redhat.com/show_bug.cgi?id=1244353 One from warnings returned by rpmlint is: ossim-data.x86_64: W: non-conffile-in-etc /etc/profile.d/ossim.sh Because ossim.sh is not configuration file but shell script (as usual in profile.d/) I had a doubt about treating this warning. So I asked on fedora-review IRC channel and there I received answer that this warning is acceptable. In the bugzilla task I received answer that for the ossim.sh file should be used %config macro. My question is: what is valid answer for this case? Thanks in advance for your help. Best regards. Marcin Haba signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Question about profile.d scripts definition in Spec file
On 02.08.2015 08:54, Ralf Corsepius wrote: On 08/02/2015 08:39 AM, Marcin Haba wrote: Hello, I am trying to make informal review following feature request: https://bugzilla.redhat.com/show_bug.cgi?id=1244353 One from warnings returned by rpmlint is: ossim-data.x86_64: W: non-conffile-in-etc /etc/profile.d/ossim.sh Because ossim.sh is not configuration file but shell script (as usual in profile.d/) I had a doubt about treating this warning. Well, I sense a misinterpretation of %config. In the context of the /etc file hierarchy %config means user-customizable, which means rpm/yum/dnf updates must not destroy any changes a user may have applied and should backup instead. So I asked on fedora-review IRC channel and there I received answer that this warning is acceptable. Well, it's a minor issue, but it definitely is arguable. In the bugzilla task I received answer that for the ossim.sh file should be used %config macro. My question is: what is valid answer for this case? My recommendation is to use %config. Hello Ralf, Thanks for your advise. I added the thread link to bugzilla ticket. If somebody has a different opinion in this matter, please answer in this thread. Best regards. Marcin Haba signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Question about profile.d scripts definition in Spec file
On 02.08.2015 12:34, Michael Schwendt wrote: My question is: what is valid answer for this case? The explanation is given by rpmlint -i …. Hello, Not really. I read output from rpmlint and I am not sure if it is unambiguous for shell scripts placed in /etc location. Please look: ossim-data.x86_64: W: non-conffile-in-etc /etc/profile.d/ossim.sh 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. Above rpmlint output text can be ambiguous because the 'executable' meaning may treat at least as: 1) have execute file permission 2) have executable scripting language code 3) ... others? In case 2) always can use interpreter to execute script. There is not need to mark execute permission on a file. It looks that exactly this situation we consider for profile.d/ scripts. Summary is that there are two meaning issues defined in these questions: A) if a shell script can be treated as configuration file? B) does in rpmlint aspect non-executable mean 'without execute permissions' or 'non-executable at all' (directly and by any interpreter) ? Since I known answer for this specific profile.d script (use %config macro), I have no longer doubt. Nevertheless the questions A) and B) still exist not answered for me, but I guess that it is subject to longer discussion and not here (off-topic). Best regards. Marcin Haba signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Question about profile.d scripts definition in Spec file
On Sun, 2 Aug 2015 08:39:28 +0200, Marcin Haba wrote: Hello, I am trying to make informal review following feature request: https://bugzilla.redhat.com/show_bug.cgi?id=1244353 One from warnings returned by rpmlint is: ossim-data.x86_64: W: non-conffile-in-etc /etc/profile.d/ossim.sh Because ossim.sh is not configuration file but shell script (as usual in profile.d/) I had a doubt about treating this warning. So I asked on fedora-review IRC channel and there I received answer that this warning is acceptable. Without a rationale, that is a questionable response. In the bugzilla task I received answer that for the ossim.sh file should be used %config macro. My question is: what is valid answer for this case? The explanation is given by rpmlint -i …. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Question about profile.d scripts definition in Spec file
On Sun, 2 Aug 2015 14:24:00 +0200, Marcin Haba wrote: The explanation is given by rpmlint -i …. Hello, Not really. I read output from rpmlint and I am not sure if it is unambiguous for shell scripts placed in /etc location. Well, it is the contents of the file that matter. The purpose of the file, not the type of file. You call them shell scripts, but all these files do, if sourced by the shell, is they alter the global runtime _configuration_ by setting environment variables for a program that may evaluate those variables. A) if a shell script can be treated as configuration file? Certainly. It's a cheap way to set a program's runtime configuration instead of implementing a full config file loader/parser. And don't forget, there is a difference between marking files as %config and %config(noreplace). B) does in rpmlint aspect non-executable mean 'without execute permissions' or 'non-executable at all' (directly and by any interpreter) ? It refers to the exec permission bit. Executables files in /etc being marked as %config would be another mistake. It's some sort of white-list to assume that files in /etc meant to be executed (such as initscripts related files) are not configuration files in any way. Admin may decide to edit such executables nevertheless (for reasons unknown), but the next update would overwrite the changes. Also not forget, rpmlint only warns about it. Not marking them %config would not be a severe mistake. It's just better to mark them %config because of the contents of these files. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Question about profile.d scripts definition in Spec file
On 02.08.2015 14:48, Michael Schwendt wrote: On Sun, 2 Aug 2015 14:24:00 +0200, Marcin Haba wrote: The explanation is given by rpmlint -i …. Hello, Not really. I read output from rpmlint and I am not sure if it is unambiguous for shell scripts placed in /etc location. Well, it is the contents of the file that matter. The purpose of the file, not the type of file. You call them shell scripts, but all these files do, if sourced by the shell, is they alter the global runtime _configuration_ by setting environment variables for a program that may evaluate those variables. Hello Michael, Thanks for your comments. A) if a shell script can be treated as configuration file? Certainly. It's a cheap way to set a program's runtime configuration instead of implementing a full config file loader/parser. My image of configuration files is that they are files for read/write purpose by design, because they enables _configure_ something (application, service, single program, script...whatever). If they are dedicated only for reading then from my point of view they lose configuration meaning (something like WORM storage ;-) ). And don't forget, there is a difference between marking files as %config and %config(noreplace). Yes, I remember about it. Thanks. B) does in rpmlint aspect non-executable mean 'without execute permissions' or 'non-executable at all' (directly and by any interpreter) ? It refers to the exec permission bit. Executables files in /etc being marked as %config would be another mistake. If rpmlint refers 'non-executable' only to the exec permission, what I believe takes place, and the contents of the file that matter for determine 'executable/non-executable' type, it means that rpmlint search 'executable' property not there where it should search. Partially I understand this searching for executable files because it might be difficult clearly qualify some file to some specific type of files basing on a file content or just interpreter definition. However I believe that exist some tools or libraries that can do this content analyze for rpmlint. It's some sort of white-list to assume that files in /etc meant to be executed (such as initscripts related files) are not configuration files in any way. Admin may decide to edit such executables nevertheless (for reasons unknown), but the next update would overwrite the changes. Good to know that mentioned white-list exists. Could you indicate me where can I find this white-list? Also not forget, rpmlint only warns about it. Not marking them %config would not be a severe mistake. It's just better to mark them %config because of the contents of these files. Yes, right. Best regards. Marcin Haba signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Question about profile.d scripts definition in Spec file
On 2 August 2015 at 15:29, Marcin Haba marcin.h...@bacula.pl wrote: My image of configuration files is that they are files for read/write purpose by design, because they enables _configure_ something (application, service, single program, script...whatever). If they are dedicated only for reading then from my point of view they lose configuration meaning (something like WORM storage ;-) ). This is probably an argument for having shell configuration fragments packaged under /usr/lib/bash/profile.d rather than /etc/profile.d. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Question about profile.d scripts definition in Spec file
On 2 August 2015 at 22:57, Jonathan Underwood jonathan.underw...@gmail.com wrote: On 2 August 2015 at 15:29, Marcin Haba marcin.h...@bacula.pl wrote: My image of configuration files is that they are files for read/write purpose by design, because they enables _configure_ something (application, service, single program, script...whatever). If they are dedicated only for reading then from my point of view they lose configuration meaning (something like WORM storage ;-) ). This is probably an argument for having shell configuration fragments packaged under /usr/lib/bash/profile.d rather than /etc/profile.d. .. or /usr/share/bash/profile.d, perhaps. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Question about profile.d scripts definition in Spec file
On Sun, 2 Aug 2015 16:29:06 +0200, Marcin Haba wrote: A) if a shell script can be treated as configuration file? Certainly. It's a cheap way to set a program's runtime configuration instead of implementing a full config file loader/parser. My image of configuration files is that they are files for read/write purpose by design, because they enables _configure_ something (application, service, single program, script...whatever). If they are dedicated only for reading then from my point of view they lose configuration meaning (something like WORM storage ;-) ). Why would you say that? There are read-only config files to set the system-wide default for everyone. The program reads them first before looking for user's local config files to override the defaults. The program would never write the system-wide file file in /etc, but at most the user's local file. And in general, whether a program can write its own config files is purely a question of design. Clearly, over the years there have been programs that only read config files somebody [or some tool] can create. /etc/bashrc, /etc/profile are examples of %config files where the file format is shell language code to be interpreted by a shell. B) does in rpmlint aspect non-executable mean 'without execute permissions' or 'non-executable at all' (directly and by any interpreter) ? It refers to the exec permission bit. Executables files in /etc being marked as %config would be another mistake. If rpmlint refers 'non-executable' only to the exec permission, what I believe takes place, and the contents of the file that matter for determine 'executable/non-executable' type, it means that rpmlint search 'executable' property not there where it should search. Partially I understand this searching for executable files because it might be difficult clearly qualify some file to some specific type of files basing on a file content or just interpreter definition. However I believe that exist some tools or libraries that can do this content analyze for rpmlint. What would be the benefit? rpmlint cannot get it 100% right anyway. There could be corner-cases, where a config file gets executed instead of being sourced like a shell include file. It's some sort of white-list to assume that files in /etc meant to be executed (such as initscripts related files) are not configuration files in any way. Admin may decide to edit such executables nevertheless (for reasons unknown), but the next update would overwrite the changes. Good to know that mentioned white-list exists. Could you indicate me where can I find this white-list? With some sort of white-list I mean the simplification -- the simplified assumption -- that files with execute permission are believed to be executables and not configuration files. And vice versa. Real configuration files being marked executable are believed to be mistakes. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
