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
pgpUv30f2tv3O.pgp
Description: PGP signature
