👍 - I very much like this change because /etc/sysconfig/ (I didn't know that was in there) is a Red Hat specific invention and not part of the FHS spec. This update gets rid of that vendor specific code and makes it distro agnostic.

@troyengel This doesn't have anything to do with /etc/sysconfig, despite the name similarity to the Makefile variable $(SYSCONFDIR) (or the RPM macro %{_sysconfdir} for that matter). We're talking about just plain /etc here.

@tonyskapunk The only problem I see with a check for the old location /etc/recap is that on RPM upgrades, the file would be renamed to /etc/recap.rpmsave if it has been modified. What do you think about having the code check for that location as well?

@carlwgeorge - you may have missed it in the diff, I was referring to the code where we are, in fact, removing the /etc/sysconfig check (I imagine this is from a long time) right here: ed24036#diff-cf77cb5672a68c31afd4bc3025d4288cL611

On the .rpmsave -- won't this happen only if the configuration file has not been edited by the end user? (matches the hash from the RPM) I'm not too familiar with the semantics when the name changes and it's been edited though at the same time. If we build in a check for .rpmsave (or maybe ,rpmnew?), should we also add the same check for whatever DEB packages do in the same conceptual ballpark? Cover all our bases?

• http://people.ds.cam.ac.uk/jw35/docs/rpm_config.html

If we have %config(noreplace) I think (if I read the chart correctly for our situation) if the user has edited the file the new one will become recap.conf.rpmnew? (http://pkgs.fedoraproject.org/cgit/rpms/recap.git/tree/recap.spec#n50)

(Edit: thinking on it, I guess the problem is RPM sees these two files as unique items, and doesn't understand they're the same file just being renamed. Hrmmm....)

Ah I see the older check now, that's what I get for skimming.

Your edit hits the nail on the head, they are two separate files. Your point about DEB semantics is noted, and actually changes my mind about having recap do any package-specific things.

What about having the RPM own both files?

Brainstorm: https://gist.github.com/carlwgeorge/eed7aaeadc4f30e729af33416be24170

I want to avoid doing something distro specific in the code, hence reading .rpmnew and others ideally should be avoided.

The purpose of this PR is:

• Introduce the new location /etc/recap.conf
• Create awareness to users of the new location under the following conditions:
  • Old and New locations exist --> Old takes precedence and a message is displayed[0].
  • Only Old location exists --> Config is loaded and a message is displayed[1].
  • Both locations are not existent --> Defaults are used and a message is displayed[2].

Now back to the package discussion.

1. Tracking two locations /etc/recap and /etc/recap.conf

   1. unedited:
      • The code is able to support this scenario, the old location takes precedence for now.
      • The code should not modify the old config, despite being the same.
   2. edited:
      • The code is able to support this scenario, the old location takes precedence for now.
      • The code should not modify the rpm saved config.

2. Tracking just the new one /etc/recap.conf
   In this case the /etc/recap will be around but it really does not matter as the code is able to read from this file as it takes precedence for now, but still will notify the user there is a new version in place.

I think tracking just one file is less effort and has almost the same result.

Thoughts?

[0]

Configuration files exist at old(/etc/recap) and new(/etc/recap.conf) locations. The file from the old location will be read. 
Please move your configuration to /etc/recap.conf.

[1]

Configuration file exists at old(/etc/recap) location.  The file will be read. 
Please move your configuration file to /etc/recap.conf.

[2]

No configuration file found. Expecting /etc/recap.conf
Proceeding with defaults.

Allow me to clarify what will happen if we simply do this in the spec file:

-%config(noreplace) %{_sysconfdir}/recap
+%config(noreplace) %{_sysconfdir}/recap.conf

unedited config

• everything happens as expected, no user interaction

edited config

• /etc/recap will be renamed to /etc/recap.rpmsave
• new default config will be at /etc/recap.conf
• since /etc/recap does not exist, the program ignores all previous customizations

I'd like to avoid that last scenario to best comply with EPEL updates policy.

Understood, then the best approach initially is to keep track of them both.

Now, for future releases how it is handled to get rid of the old /etc/recap ?

I want to know if there is anything the code should take into consideration but at the same time I want to avoid being too distro specific as reading .rpm{new,save} as my intentions in the following releases are:

• 1.4.0:
  • Create awareness of /etc/recap but now make /etc/recap.conf to take precedence.
  • If /etc/recap.conf is missing but /etc/recap is found the latter is read.
• 1.5.0:
  • Ignore /etc/recap, /etc/recap.conf is read otherwise defaults are used.

Oh, just realized that forgot to tag @carlwgeorge in my previous comment, any thoughts on the path of deprecation? If all looks good I'll go ahead and merge. Thanks!

I agree about avoiding reading .rpmsave/.rpmnew files. I need some more time to think through the best way to handle the migration on the RPM side. Specifically I want to see how the rpmsave/rpmnew mechanism would work if /etc/recap is a symlink to /etc/recap.conf.

Hi @carlwgeorge sorry for the pressure with this one, since I'm looking into releasing 1.3.0 next week I'll like to know how are we feeling about this change and if I should delay it one more release to give you more time solving the packaging situation.

Thanks!

Rebased to include the now support of logging in recap

After tinkering with this a bit, I think our best option is to implement the rpmsave file handling via a %posttrans scriptlet.

%posttrans
if [ -f /etc/recap.rpmsave ]; then
    mv -v /etc/recap.conf /etc/recap.conf.rpmnew
    mv -v /etc/recap.rpmsave /etc/recap.conf
fi

Here is what would happen during the transaction:

1. recap-$NEW with /etc/recap.conf would be installed.
2. recap-$OLD with /etc/recap would be uninstalled.
3. If /etc/recap was customized, it will be moved to /etc/recap.rpmsave.
4. The %posttrans script is run, and if it detects /etc/recap.rpmsave, it moves /etc/recap.conf out of the way and puts the customized config file in it's place.

The actual recap script can handle the transition however you like, I'll just add that to the spec file as soon as reading /etc/recap.conf is supported.

👍 - I like it. Is there any concern if - somehow, not sure how - an existing /etc/recap.conf.rpmnew is already on disk? It would get clobbered, but I think in RPM terminology even if that did happen the .rpmnew file means "I'm the unedited version from an RPM" so there's no altered content in there, yah?

Edit: in this edge case, wouldn't that cause an RPM to stall if it asks "are you sure?"? Perhaps we need mv -vf ... just in case?

the .rpmnew file means "I'm the unedited version from an RPM" so there's no altered content in there, yah?

👍

No different than if subsequent package updates had new config files. For example if -2 and -3 each had a different config file from -1, and you updated through each one, -3's .rpmnew file would overwrite -2's .rpmnew file.

Good point on the force flag, I'll make sure to use that in the actual spec file.

To recap-itulate ;) ...

• If the old /etc/recap config is unedited it will be uninstalled and the new config /etc/recap.conf will be used.
• If the old /etc/recap config is edited, it will be moved to /etc/recap.conf to remain in use, the new /etc/recap.conf will be moved to /etc/recap.conf.rpmnew.

Subsequent releases will behave exactly the same, leaving the edited config file in /etc/recap.conf and the config file from the package in /etc/recap.conf.rpmnew.

It will be up to the user to ensure they switch to the latest configuration.

Merging this one into development