Question about profile.d scripts definition in Spec file

[Marcin Haba]

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 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.

So, maybe better for profile.d to use %config(noreplace)?

> 
> 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.

Best regards.
Marcin Haba

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150803/f91d73a5/attachment.sig>