[pacman-dev] backup handling ugly mess

Xavier shiningxc at gmail.com
Thu Dec 6 02:56:28 EST 2007

On Wed, Dec 05, 2007 at 08:25:54PM -0600, Dan McGee wrote:
> OK, so I think I understand the problem here, and it makes sense. It
> seems like manipulating backup arrays and merging them is probably a
> bad idea.
> Let me get this straight- your patch doesn't actually solve these
> problems, just makes the existing code work as we thought it would?


> Let's start by laying out a set of rules that pacman should follow,
> then seeing if our pactests represent these cases. I'm only going to
> cover upgrades, because removals are straightforward (always create
> pacsave files of those in the backup array).
> 1. If the file is in the old backup array, and is then removed from
> the backup array AND package, we should move it to pacsave.
> (upgrade024?)


> 2. If the file is in the old backup array, and is then removed from
> the backup array BUT stays in the package, we have a gray area. We
> need to choose- either install the new file as pacnew and leave the
> old file (which would then be overwritten on the next upgrade because
> it is no longer in the backup array, so probably not the best
> solution), or do as upgrade025 does- move the existing file to pacsave
> and install the new file.

yes, updrade025 looks alright.

> 3. If the file is in the old backup array, and stays in the backup
> array BUT is removed from the package (bash), we should probably move
> (or should we copy and leave the original?) the file to pacsave. This
> is a gray area.

This is a really odd case, but well, I would say just move it to pacsave,
because otherwise, it just let a normal file on the filesystem, without a
.pac* suffix, not owned by any packages.
So when you install a package that adds this file again, it'll conflict.

That is upgrade026.

> Note that we haven't even looked at the new backup array yet. I think
> it may have been a bit naive to introduce that without much testing...
> 4. If the file exists in the old package BUT is not in the backup
> array, but is in the backup array of the new package, we should either
> install the new file as pacnew OR move existing file to pacsave and
> install new file in original location. Not sure here.

I think this should be handled just like the common case :

5. If the file exists in both old package and new package, and both backup
arrays, then we let the md5sum logic in add.c decide if a .pacnew needs to be
extracted or not.

> Comments please, especially if I missed hard cases. Once we get this
> hammered out this needs to be documented somewhere.

There are probably other weird cases, but if all the above are handled
correctly, it should be good.

More information about the pacman-dev mailing list