[arch-dev-public] keep config file on system when upgrading to package without the config file

[Aaron Griffin]

On Wed, Mar 17, 2010 at 12:56 PM, Dan McGee <dpmcgee at gmail.com> wrote:
> On Wed, Mar 17, 2010 at 11:55 AM, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
>> On Wed, Mar 17, 2010 at 8:03 AM, Daenyth Blank <daenyth+arch at gmail.com> wrote:
>>> On Wed, Mar 17, 2010 at 06:27, Ronald van Haren <pressh at gmail.com> wrote:
>>>> So the new package doesn't have the config file anymore and is now
>>>> removing the old file (it seems it doesn't matter if the file is in
>>>> the backup array or not). Any way around this so I can quickly fix
>>>> this and people won't come in the grub shell upon next reboot ?
>>>>
>>>> Ronald
>>>>
>>> I don't think this is possible internally. One because it would leave
>>> unmarked untracked files on /, secondly because internally an upgrade
>>> is a remove+install
>>
>> I actually thought pacman USED to do this. If a file is in the backup
>> array, and it is being removed, it is moved to .pacsav. Wasn't that
>> the logic, or am I crazy?
>
> Yeah, we have some complete lies being posted in this thread. I
> haven't looked at the package in question but I don't buy that I've
> heard the full truth here.
>
> 1. upgrade is not a remove+add, it does a hell of a lot more (ever try
> to handle backed-up files moving between packages on a system update?
> pacman does)
> 2. Config files in a backup array ****NEVER**** get deleted, except
> for one case- you've never changed it and moving to either a version
> of a package that doesn't have that file or uninstalling the package.
> 3. Files move to .pacsave if they are removed, never deleted (except
> the condition above)
> 4. Please look at the pactest/tests/ directory in the pacman directory
> if you want to see how backup file handling works with real examples.
> In particular, remove010, remove011, remove020, remove021,
> upgrade020-26, upgrade042, upgrade043, and upgrade045. (yes, there are
> that many tests for this stuff)

I remember doing a redux of some of the backup array code way back
when, and I was fairly certain this was the case.

Perhaps the tests of grub2 are hitting the condition in #2 here.