On 3/23/20 3:21 PM, michael.lienha...@laposte.net wrote: > ----- Zac Medico <zmed...@gentoo.org> a écrit : > >>> 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. >> >> That's true if the package is removed via emerge --depclean, but emerge >> --unmerge does not account for dependencies. >> >> Also, it's possible for dependencies of installed packages to be >> temporarily broken by upgrades. In cases like this, the breakage will >> eventually be resolved by a rebuild (which occurs automatically for slot >> operator := deps), upgraded, or by emerge --depclean (which removes >> unneeded packages). > > Many thanks for your answers. > They made me realize that the problem I'm facing is a bit more tricky than I > first quickly though. > > I'll try to explain the problem, tell me if I'm not clear somewhere. > > The goal of my tool is to have correct manipulation of package dependencies, > and in particular here, I focus on the packages that are installed but not in > the portage tree/a local overlay anymore (the problem does not occur for > other packages). > It seems that installed packages do not store which are the actual cpv they > depend on. Correct?
Right, because unfortunately that's something that changes over time. Also, we may not be able to pin it down at any given moment if we have inconsistent || preferences as described here: https://archives.gentoo.org/gentoo-dev/message/550d3859dea6d0fb0b39064628992634 > Hence, when an installed package cannot be updated/recompiled because it is > not in the tree anymore, like you said, its dependencies can be broken (due > to the package it depends on being updated). > Currently, this issue is circumvented (only using depclean) by keeping the > libs: the package's dependencies are broken, but it's ok because it can still > run (which, in the end of the day, is what we want). > However, from your answer, it seems that this fix is not entirely integrated > in the emerge/portage toolchain (like you said, emerge --unmerge removes > everything, and emerge -u removes the old libs). > > To sum up, the problem I'm facing is that with the current way installed > packages are managed, we can break dependencies (and the only way to fix them > is to remove the installed package with the broken dependencies, that can > never be installed again). > > Hence, for my tool, I have two solutions for that problem: either I forbid > for dependencies to ever be broken, or I allow it. > > Solution 1: forbid broken dependencies. > This requires to extend the information stored on installed package with the > list of the actual cpvs they depend (or at least the cp+slot, which is enough > to get back the cpvs). > That way, I can say in the solver "if you want to keep that package, you need > to keep these packages as they currently are". > However, I have no idea on how to do that, and doing this only for my tool > would mean that one cannot switch between emerge (quick) and my tool > (correct), which is a feature I think is essential. > Do you think adding this new information to installed packages could be > integrated into emerge/portage itself? I could work on it (expect question > ^^), test it on my prototype, and do a pull request when everything's working. It's possible to store this information in a cache of the most recently calculated dependency graph. > Solution 2: allow broken dependencies. > Here, the idea is to use the same fix as is currently done with depclean, but > in my tool's planner (i.e., the part that install/unistall the packages) > directly. > That way, I say in the solver "that installed package has no dependency", but > when I upgrade/remove packages, I say "Oh but wait, that other package still > need these libs, let's keep them". > This solution may not require any change in portage/emerge, but I have no > idea on how to know which libs are needed by a package, and how to track > these libs owners without looking at every installed package's files (which > are stored in the CONTENT file, if I'm not mistaken). For soname dependencies, we've got PROVIDES and REQUIRES metadata. > Also, I wanted to use the ebuild tool to install/uninstall package, which is > not possible with this solution apparently. Why not? Would the preserve-libs feature solve your problem? > In case I need to implement this, could you give me some clue on how to > achieve it? > > > Among these two solutions, I prefer the first one: we stay at the level of > package dependencies (and it looks simpler to implement). > However, it is maybe easier/better to use the second approach, I don't know. > Do you have some suggestions? Well, there are a lot of upgrades that can't be performed without temporarily breaking something, so the "forbid broken dependencies" idea doesn't sound feasible to me. > Thanks! > Michael -- Thanks, Zac
signature.asc
Description: OpenPGP digital signature
