<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 24, 2020 at 11:31 AM <<a href="mailto:michael.lienhardt@laposte.net">michael.lienhardt@laposte.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br> ----- Zac Medico <<a href="mailto:zmedico@gentoo.org" target="_blank">zmedico@gentoo.org</a>> a écrit :<br> <br> > > 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).<br> > > It seems that installed packages do not store which are the actual cpv they depend on. Correct?<br> > <br> > Right, because unfortunately that's something that changes over time.<br> > <br> > Also, we may not be able to pin it down at any given moment if we have<br> > inconsistent || preferences as described here:<br> > <br> > <a href="https://archives.gentoo.org/gentoo-dev/message/550d3859dea6d0fb0b39064628992634" rel="noreferrer" target="_blank">https://archives.gentoo.org/gentoo-dev/message/550d3859dea6d0fb0b39064628992634</a><br> <br> Hmm, I think I see what you mean.<br> Storing the cpvs that was used during solving the package's dependencies would be too restrictive, since two different packages could provide the exact same functionalities/libraries.<br> And so, during a system update, only looking at the cpv dependencies would trigger useless recompilation of the packages that depend on the updated packages.<br> Correct?<br> <br> Btw, my tool's solver does not have the problem discussed in the thread you're mentioning: atom order in lists has no influence in my solver.<br> Would fixing the inconsistent || preferences make storing cpvs for installed packages more realistic?<br> <br> <br> > > Also, I wanted to use the ebuild tool to install/uninstall package, which is not possible with this solution apparently.<br> > <br> > Why not? Would the preserve-libs feature solve your problem?<br> <br> ... I'm sorry, I wasn't aware of this feature.<br> It would definitively solve the issue (except, as described in the bug 459038, when external tools remove libs).<br> <br> This discussion is very interesting!<br> If I take this double layer of dependencies, I have to check how this influences the theory underlying my tool.<br> <br> However, I still doubt that only storing the soname dependencies is enough.<br> Consider package A (that cannot be recompiled) that depends on package B which provides lib L.so.<br> B is recompiled with different use flags, which put different functionalities in L.so.<br> The dependencies of A are still satisfied (B is installed, L.so is available), but since the content of L.so changed, A cannot execute anymore.<br> Hypothetically, can this scenario occur?<br> Can this scenario occur in practice?<br> Is there a way in emerge/portage to avoid it?<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br> <br> > Well, there are a lot of upgrades that can't be performed without<br> > temporarily breaking something, so the "forbid broken dependencies" idea<br> > doesn't sound feasible to me.<br> <br> Could you tell me about several instances of such needed dependency breakage?<br> You have far more experience than me on this, and it would be nice for me to know what I'm up against.<br></blockquote><div><br></div><div></div><div>A lot of this has to do with the specifics of how package managers manage system state, as well as various quirks of subsets of the tree. For example, a perl upgrade (X->Y) will often break perl modules who expect perl-X, but get perl-Y. So one fix is to try to keep perl-X installed (so we SLOT perl and have N perls installed.) Then you need to decide which version of perl to build things against (X or Y, or both?) We took this tactic in the python ecosystem; but perl is not slotted in Gentoo, and so upgrading perl breaks all perl modules. There is a tool (gentoo-perl-cleaner) that will walk the deptree and fix all of these broken packages that you run after an upgrade.</div><div><br></div><div>I'm not sure it's strictly avoidable. You could build perl-Y, then rebuild all perl-modules against perl-Y, then merge the entire result to the livefs. This will reduce the breakage time but likely not eliminate it; plus it seems hard to implement in practice without modern filesystem tools (overlayfs, btrfs, zfs or similar tech to make it atomic.) It also doesn't account for executing code. What happens to perl-X code that is executing when you unmerge perl-X? The short answer is that code might break and 'proper' management means you should restart services after an upgrade (something Gentoo doesn't typically do; but is common in Debian for example.)</div><div><br></div><div>-A<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> Many thanks!<br> Michael<br> <br> </blockquote></div></div>