Re: [gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Andrew Savchenko]

Hi,

On Sun, 24 Jul 2016 03:00:40 +0000 (UTC) Duncan wrote:
> Andrew Savchenko posted on Sun, 24 Jul 2016 00:30:39 +0300 as excerpted:
>
> > Do we ever had such case like multiple versions of the same
> > single-slotted package installed or recorded as installed in the real
> > world? I'm not sure even in this, but I may assume that it may happen
> > one day.
> >
> > Do we have any proof that PM can recover from such situation,
> > where VDB is a mess and installed files can also be a mess? I'm not sure
> > in this at all.
> >
> > Do we have any test suits for portage (as the most popular PM
> > implementation) for such cases? I doubt this, I can find none. I'm not
> > sure if such tests are implemented in other PM test suits too.
>
> Think of how a package is upgraded (by portage, I don't know enough about
> the others to describe the process for them).  The package is built, then
> installed to a temporary location, then "qmerged" from the temporary
> location to the live filesystem, replacing the previous version's files
> and recording the new one in the installed-package database, then the old
> version is unmerged and its record removed from the installed-package
> database.
>
> What happens if there's a crash in either the qmerge or old-version
> unmerge steps?
>
> Right, now there's parts of two versions in the installed-package
> database, and who knows what files from each on the live filesystem.
>
> I'm not a portage dev so won't comment on the test suite angle, but
> portage has been able to handle this with the user simply redoing the
> upgrade (whether from binpkg or full rebuild) for many years now (singe
> before I became a gentooer in 2004, I know as I had some faulty hardware
> at the time and regularly crashed during build and installs, which was
> likely before REPLACING_VERSIONS was a thing), and given the number of
> installations out there and the stress of parallel-building some packages
> while others are installing, the code to handle this is GOING to get
> regularly tested.

I agree with you, but REPLACING_VERSIONS has nothing to do with
such recovery.

1) It appeared only in EAPI 4, approved on 2011-01-17. Recovery
from hardware crashes forked well long before.

2) If you will look into the tree, in the absolute majority of cases
REPLACING_VERSIONS is being used to determine whether informational
messages should be shown to a user or not. Such messages usually
include some upgrade hints or howtos; and REPLACING_VERSIONS check
is required to avoid showing them to unaffected users. It has
absolutely nothing to do with the error recovery done by PM itself.

3) I also had a broken hardware (faulty memory) for a few years and
portage and other software recovered quite fine despite numerous
segfaults. So I have the experience :)

Best regards,
Andrew Savchenko