On Dec 6, 2007 1:56 AM, Xavier <shiningxc@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