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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
