FS#8645 - Restore pacsaves on an install

Attached to Project: Pacman
Opened by Aaron Griffin (phrakture) - Thursday, 15 November 2007, 18:37 GMT
Last edited by Allan McRae (Allan) - Thursday, 03 September 2020, 04:47 GMT
Task Type Feature Request
Category General
Status Closed
Assigned To Aaron Griffin (phrakture)
Dan McGee (toofishes)
Architecture All
Severity Low
Priority Normal
Reported Version 3.0.6
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Random idea I had just now.

If I pacman -R foobar, I get left with a /etc/foobar.conf.pacsave if I made changes, but the package is gone.

If I then pacman -S foobar again, we could flip-flop these. The pacsave file gets moved to the real conf file, and the one in the package moved to pacnew

Opinions?
This task depends upon

Closed by  Allan McRae (Allan)
Thursday, 03 September 2020, 04:47 GMT
Reason for closing:  Won't implement
Additional comments about closing:  This idea is too prone to causing unintended breakage. Pacman should leave these files alone.
Comment by Dan McGee (toofishes) - Thursday, 15 November 2007, 19:07 GMT
This doesn't seem like a bad idea. I'd make sure we lay out all scenarios first though. I can think of one issue- if the pacsave file is really old and incompatible with the new one, users might be confused that a package doesn't work out of the box.

If we do this, a message saying what was done is a must.
Comment by Roman Kyrylych (Romashka) - Wednesday, 16 January 2008, 23:55 GMT
IMHO this is not very needed and bug-prone. If this is going to be implemented - a really good testing of all cases should be made.
Comment by Daniel D. (danieldanner) - Saturday, 05 July 2008, 12:37 GMT
I'd really appreciate this feature.

In all cases where the configuration file (without the .pacsave postfix) isn't already present for any reason (on reinstalls, for example) this operation should be perfectly save and intuitive as long as a .pacnew is created, shouldn't it?

In which way could it be bug-prone, Roman?
I don't see any risk of data loss and problems with incompatibility are possible with the current .pacnew file creation, too.

Dan, if the user has such an old pacsave file lying around, he's probably not a newbie. ;) Also, reading pacman's output carefully should pull everyone's attraction on the newly created .pacnew file to check for neccessary merging...
Comment by Nagy Gabor (combo) - Saturday, 05 July 2008, 13:52 GMT
I have one more reason.
Without deeper overthinking, I feel that this could be used to simplify upgrade .pacsave handling (upgrade == remove + add).
Comment by Allan McRae (Allan) - Saturday, 05 July 2008, 17:36 GMT
For reference, this was my first attempt a doing this:
http://archlinux.org/pipermail/pacman-dev/2008-May/011715.html

Once someone helps me figure why that pactest broke, I will add the user interface parts.
Comment by Xavier (shining) - Saturday, 05 July 2008, 22:10 GMT
On the other hand, Nagy talked about simplifying the pacsave handling, not complicating it :)
But I agree that this whole problem is not obvious at all and would require additional explanations and discussions on the ML.
Comment by Gavin Bisesi (Daenyth) - Thursday, 28 August 2008, 15:14 GMT
Personally I'm against this. I'd much rather do this manually. Also there is no guarantee that the config file format hasn't changed since you removed the package.
Comment by Daniel D. (danieldanner) - Thursday, 28 August 2008, 15:22 GMT
Yeah, but this is an issue we have with ANY upgrade, no matter if the package has been removed before.
Comment by Allan McRae (Allan) - Saturday, 04 August 2012, 03:21 GMT
Restoring a potentially old and broken .pacsave file is a bad idea. So I'm going to propose a different approach is taken...

How about just printing a message when a file in the backup array is installed and there is an existing .pacsave file?

Loading...