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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
