Question about profile.d scripts definition in Spec file

[Michael Schwendt]

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.