[pacman-dev] backup handling ugly mess

[Dan McGee]

On Dec 6, 2007 1:56 AM, Xavier <shiningxc at gmail.com> wrote:
> 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.

So given all this- do you want to go ahead and try to patch it so we
get the expected behavior? I think your patch is a step in the right
direction (although we may end up changing the way old & new backup
arrays are combined because of some of the above). The biggest
weirdness is our backup logic has to be split in two places- the
remove and add code- and they can't really talk to each other easier
unless we make much bigger changes. I'd prefer to have a small patch
now and maybe overhaul this later once we get a release out the door.

-Dan