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