Arch Linux

the first one true...
the second one i wouldn't like, i just add any modified file to noupgrade.
I never change the udev rules for example, but every time it will be asked.

For the second option: see also bugs #1925 and #3644 for more info.
AFAIK most of config files are modified by users. So it would be better to reverse current Pacman's behaviour.
If this will be done then you should add udev rules to AllowUpgrade and they will be upgraded automatically.
This solution seems much better for me.

[arjan@alpha etc]$ sudo find . -type f | wc -l
472

This is the count of all files in my /etc. So i if we reverse the way pacman works, so we can imitate the horrible gentoo way. i will have a hell of a job to change every change there is.
And even you will probably not have changed over an 100 files.

Oops, just checked #1925 and #3644 and saw your comments there. :-)

I've read your comments yet again and I still think that current Pacman's behaviour should be reversed.
Right now I must add almost all config files to NoUpgrade. It is very easy for user to forget to include modified file in NoUpgrade.
If things gets reversed then I should add only few files to AllowUpgrade.
The main thing is that modified files that are not included in NoUpgrade (if user forgot this, or if user misspelled filename) wil not get overwritten by Pacman in upgrade process! In most cases old config file will not stop package from working. So why not made this change in 0.8?

Are my arguments bad??? I think it worth implementing this change in Pacman (at least in CVS) and see how this will work. I'm sure that it will make things easier.

yes your arguments are bad. I hate the way gentoo did solve this in the same way, after each update i spend 30 min tinkering with each etc-update thing, at least i thought it was.

I have 472 files in my /etc and about 30 files in my noupgrade list. so on your way i should have around 730 files in my noupgrade list.

See: http://bugs.archlinux.org/task/3644#comment7466 (the first part only, the second is another thing).

Maybe we should start a separate discussion on forum or Flyspray?

There is another solution (just came in my mind):
when upgrading package Pacman should check if modification date/time of package's config files are newer than package installation date/time, and then make decission "to upgrade or not to upgrade" :-)
Any comments?

well, i do not like that at all, you allready said the comment, more then once.
You seem not want to read my comments, again i would have to add 730 files to allowupgrade.
If this would change i would need to find another distro. I like the way it is handled right now.

In first place i made the mistake also not to add files to the noupgrade list, you make this mistake ones or twice and then you will learn to work with it and love it.
We as package maintainers add backup=() for files that should be saved to .pacsave, The only change that might be interresting to do is to save all old configs to .pacsave .

hmmm we do not want user input on upgrades/installs, but the idea would be nice to use for saving it to .pacsave files ?

so the implementation would be like:
check if modification date is changed for the package ->
check if it isn't in noupgrade ->
save the config file to .pacsave.

I think this would be an neat feature for pacman.

Sorry, we just writing comments too fast, so this page gets updated vefore someone finished writing comment. :-)

Note 1: When installing package mtimes of installed files are the same as of files from tar.gz.
(I hope that there are no packages that have some of their config files modified automatically each time when package maintainer compiles new version).
Note 2: When mtime of config file is greater than ctime of file - this means that config file is modified by user.

All upgrade process can be as following:

for each config file in package compare mtime of config file with mtime of new config file, then:
1) existing config file is newer (or mtimes are the same) - do not upgrade this file
2) new config file (default config file of package) is newer:
a) file is in NoUpgrade - save new file as .pacnew
b) file is not in NoUpgrade:
b1) file is not modified by user (see Note 2 above) - upgrade this file, saving a copy as .pacsave
b2) file is modified by user - do not upgrade file, save new file as .pacnew

Sounds a bit complicated, but should work fine. Anyway more testing needed.
All these are just ideas. If this will be implemented and which way - it is developers' choice.

blaasvis, thanks for discussion. :-)

I think Roman's proposition makes sense. However, I would propose slightly different behaviour:

* Overwrite config if there are changes to the STOCK version and the LOCAL version has not been altered
* If new STOCK version and LOCAL config is altered (i.e. custom):
1) save NEW file to .pacnew if NoUpgrade
2) prompt otherwise.

Note 1) In most of the cases the shipped config identical to shipped config from the last version. Just checking for this solves most of the problem.

Note 2) I think an UNALTERED config file should ALWAYS be overwritten by DEFAULT. I can't think of any situation where this would cause trouble.

Note 3) Since changes in shipped configs don't seem to be very common, I think that most users would be OK with pacman prompting what to do in this situation,

Note 4) There are some situations where it would be preferable to have upgrades finish without intervention (i.e. servers). So, it would be nice if one could instruct pacman to assume yes or no on all overwrite queries.


Does this seem reasonable to both of you?

Thanks, Jan! Nice comments. I agree.
The main possible problem here is the correctness of determining if file was altered. Comparing ctime and mtime as I described above seems to be OK, but anyway there should be more real-world testing.
I think Pacman developers and users should do extensive testing of this issue, maybe there will be new (3.0 ?) or modified Pacman in [testing].

P.S.: Someone knows something about current Pacman's development? I could not find much information about this. Please point me to some source where I can get more information.

in that case (original=X, current=Y, new=Z (as stated in the pacman's manpage)) I'd also prefer pacman leaving the current (Y) unchanged by default and the new (Z) save as .pacnew. I've seen this behaviour on Slackware and IMHO it's better (and more secure) to rename some files manually than later fixing (or reconfiguring) broken system.

btw frugalware now has that implemented in their fork of pacman
http://wiki.frugalware.org/FwPacman
frugalware-darcs@frugalware.org/msg03556.html"> http://www.mail-archive.com/frugalware-darcs@frugalware.org/msg03556.html

Thanks for links, Tomas!
Hmmm... FwPacman's additions seems very good for me. Is something of this planned for Arch's Pacman?

As of 2.9.8, pacman's default behaviour when dealing with an X,Y,Z scenario will to be write a .pacnew file (instead of the old behaviour where we wrote a .pacsave).

This means that the only time config files are overwritten is when they have been untouched by the administrator.