Question about profile.d scripts definition in Spec file

[Michael Schwendt]

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