[pacman-dev] backup handling ugly mess

[Xavier]

On Thu, Dec 06, 2007 at 05:54:17PM +0100, Nagy Gabor wrote:
> Hi!
> 
> First of all, as I see, you simply forgot about the fact that we have clear
> definition about modified ["important"] and not modified ["can be reinstalled
> easily, user did not work on this file at all, so there is nothing to lose"]
> backup files in our manual (using md5sum). This is the reason for most of your
> "grey" areas. [EDIT: I noticed Xavier's 5th point now.]
> I also prefer the configfile terminology here, because that is more suggestive. 
> 

The 5th point is just the common case, which is the only one that is really
covered by pacman, and described in the manual.
I only added it because I thought the 4th point could be handled just like
the normal one.

Dan only mentioned the unclear cases that need to be covered by pacman. What
is wrong with that?

> > 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).
> 
> I'm not sure. IMHO unmodified files can be removed.
> 

Ok right, pacsave renaming really needs to be done only for modified files,
but this is an improvment that could be made later.
What's more important in my opinion is to make sure that potential
modifications are not lost, and that the file doesn't stay in the way.
Moving to .pacsave takes care of both problems.

> > > > 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.
> 
> This is not necessarily an odd case.
> Imagine a package, where the config file is born after package install (by a
> graphical utility, or by post_update script...) <- we can confuse pacman easily
> here [we _must_ assume (and DEFINE) that the post_install script doesn't modify
> backup files, otherwise .pacnew would be useless]
> 

I think that's an odd case which should be avoided.

> > > > 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.
> > > >
> > >
> 
> Imho we can simply remove the old file here.
> 

Did you really understand what proactive backup was about?

> > > 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.
> 
> Hmm. This is not implemented yet?;-) [see EDIT;-]
> 

Not sure what you mean here. That case is already implemented correctly, I
was just saying the 4th case could be handled the same way.