[pacman-dev] /etc/fstab rewritten by pacman!

[Dan McGee]

Forwarding to pacman-dev.

---------- Forwarded message ----------
From: CHANTRY Xavier <xav at chantry.homelinux.org>
Date: Apr 10, 2007 6:37 PM
Subject: [pacman-dev] /etc/fstab rewritten by pacman!
To: dpmcgee at gmail.com


> I wonder if this is biting us:
> http://www.archlinux.org/pipermail/pacman-dev/2006-December/000838.html
>

Most certainly.

> Roman, before you update, it would be interesting to get the three
> different md5sums and see if this is the case. I'm just super
> surprised that this never happened to me in all of my pacman updates.

I was also very surprised, but you explained it clearly below :)

> If this is it, then these should be the steps to reproduce (note that
> these reports are starting at step 5, the other stuff happened in the
> past):
> 1. Install a package that had a NoUpgrade line.
> 2. Edit a backup file.
> 3. Upgrade the package, causing the local md5sum to be written to the
> DB (instead of the original md5sum from the new package).
> 4. Do NOT edit the file again, and remove the NoUpgrade line from pacman.conf.
> 5. Upgrade the package, causing the 'original' and 'old' md5sum to be
> identical, which allows pacman to write an upgraded file over your
> custom config.

That's indeed when either 3 or 4 are missing that we avoid the bug.
Once the config files have been edited, the package need to be upgraded at
least once for the wrong checksums to be stored.
So if NoUpgrade lines are removed before the damage is done, the bug
doesn't happen.

> Possible fixes:
> 1. Put NoUpgrade lines back in. This is hacky/ugly IMO.
> 2. Back up all config files that are to be overwritten as .pacold
> files, even if they are supposedly legal candidates for overwriting.
> This will cause some clutter on systems, however, but will ensure no
> configurations are lost (although they would be moved).

Like I said the on the forums :
http://bbs.archlinux.org/viewtopic.php?pid=242384#p242384
the original plan was apparently to not remove NoUpgrade in the first place,
and wait long enough so that it's safe to remove them.
It could take a while though, before the last user updates the packages
with NoUpgrade files using pacman 3, so that all checksums are corrected.

Maybe the few packages containing NoUpgrade files should be forced
to be reinstalled, after pacman 3 is installed. I'm not sure that's
100% bullet proof though. Maybe checking all checksums in the db would
be safer.

I've my part of responsibility in this problem, because I'm the one who
started complaining about NoUpgrade, because it actually caused clutters,
and it made it harder to keep all config files up to date.
So 2. would cause even more clutters, which is quite contradictory,
but well, if it's the only way..
I'm glad of pacman behavior once the transition is made, I already noticed
the transition caused problems back then. But unfortunately, no one
found a correct solution to it yet.

> Thoughts? Am I right on this? I wasn't deep enough in pacman yet when
> this issue came up.

You look perfectly right to me (not that it means anything), but what
disturbs be me highly is the behavior Roman describes.
He claims he already did an upgrade of filesystem without NoUpgrade lines,
so that should have put the correct checksums in the database.
How could the bug be reproduced after that?