| 1 |
On 3/22/20 5:38 PM, michael.lienhardt@×××××××.net wrote: |
| 2 |
> Dear all, |
| 3 |
> |
| 4 |
> Still in the process of improving my solver (and make it a usable tool), I need to have a better idea on how installed packages should be managed. |
| 5 |
|
| 6 |
Great! |
| 7 |
|
| 8 |
> I didn't find anything on that topic in the PMS (if I've missed it, I'm sorry). |
| 9 |
> Could you confirm/correct my following understanding: |
| 10 |
> 1. installed packages that are still in the portage tree can be unmerged/updated without any restriction (as specified in their .ebuild) |
| 11 |
|
| 12 |
True. |
| 13 |
|
| 14 |
> 2. installed packages that are not in the portage tree can only be kept as is or unmerged |
| 15 |
|
| 16 |
Installed packages may also implement pkg_config and pkg_info phases |
| 17 |
that can be executed via emerge --config and emerge --info. |
| 18 |
|
| 19 |
> 3. before removing a library, "ebuild unmerge" always checks if it is used by another package: this means that installed packages' dependencies are never broken. |
| 20 |
|
| 21 |
That's true if the package is removed via emerge --depclean, but emerge |
| 22 |
--unmerge does not account for dependencies. |
| 23 |
|
| 24 |
Also, it's possible for dependencies of installed packages to be |
| 25 |
temporarily broken by upgrades. In cases like this, the breakage will |
| 26 |
eventually be resolved by a rebuild (which occurs automatically for slot |
| 27 |
operator := deps), upgraded, or by emerge --depclean (which removes |
| 28 |
unneeded packages). |
| 29 |
|
| 30 |
> |
| 31 |
> Many thanks! |
| 32 |
> Michael |
| 33 |
> |
| 34 |
-- |
| 35 |
Thanks, |
| 36 |
Zac |
Archives