| 1 |
>>>>> On Fri, 06 Aug 2021, Joakim Tjernlund wrote: |
| 2 |
|
| 3 |
> On Wed, 2021-06-23 at 13:33 +0200, Michał Górny wrote: |
| 4 |
>> On Wed, 2021-06-23 at 12:40 +0200, Ulrich Mueller wrote: |
| 5 |
>> > I don't think that the ebuild can rely on any particular status of |
| 6 |
>> > the new package in pkg_*rm (of the old package), or the status of |
| 7 |
>> > the old package in pkg_*inst (of the new package). |
| 8 |
>> |
| 9 |
>> I would even say that it can't rely on the particular status of the |
| 10 |
>> old package in any case, if it's meant to be removed. In particular, |
| 11 |
>> its dependencies can be unmerged before the package itself. |
| 12 |
|
| 13 |
> Stubled ove this mail again and noticed "its dependencies can be |
| 14 |
> unmerged before the package itself" stmt. That does not make sense to |
| 15 |
> me. Deps should be unmerged after any pkg that depends on them? |
| 16 |
|
| 17 |
A popular workflow is "emerge -c -p" followed by "emerge -C" on entries |
| 18 |
of the list shown. IIUC emerge -C doesn't do any dependency resolution, |
| 19 |
therefore ebuilds cannot rely on any removal order. |
| 20 |
|
| 21 |
Ulrich |
Archives