On Thu, Aug 5, 2021 at 9:23 PM Ulrich Mueller <u...@gentoo.org> wrote: > > >>>>> On Fri, 06 Aug 2021, Joakim Tjernlund wrote: > > > On Wed, 2021-06-23 at 13:33 +0200, Michał Górny wrote: > >> On Wed, 2021-06-23 at 12:40 +0200, Ulrich Mueller wrote: > >> > I don't think that the ebuild can rely on any particular status of > >> > the new package in pkg_*rm (of the old package), or the status of > >> > the old package in pkg_*inst (of the new package). > >> > >> I would even say that it can't rely on the particular status of the > >> old package in any case, if it's meant to be removed. In particular, > >> its dependencies can be unmerged before the package itself. > > > Stubled ove this mail again and noticed "its dependencies can be > > unmerged before the package itself" stmt. That does not make sense to > > me. Deps should be unmerged after any pkg that depends on them? > > A popular workflow is "emerge -c -p" followed by "emerge -C" on entries > of the list shown. IIUC emerge -C doesn't do any dependency resolution, > therefore ebuilds cannot rely on any removal order.
Not quite sure I follow. Let's assume I have A -> B -> C. Is it legal for A to call a binary packaged in A in A's pkg_prerm? If yes, then B and C have to be on the livefs at least until A's pkg_prerm has run; right?; otherwise if we unmerged B or C before then we might break A's binaries? -A > > Ulrich
