[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?
> 

Exactly.

> 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?)

ok.

> 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.
> 

(upgrade023)
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