Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 938932 - sys-apps/portage full complete graph feature request
Summary: sys-apps/portage full complete graph feature request
Status: UNCONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Linux
: Normal enhancement
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-09-02 16:55 UTC by Lagu
Modified: 2024-10-11 20:47 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lagu 2024-09-02 16:55:16 UTC
Hi all!

I has been using gentoo for a lot of time, and I have noticed some aspects that has been making hard update the system.

I maybe have a complex system, in the sense of too much packages of different things, so update rn is hard, too hard, usually emerge is not able to solve fully the dependency graph, I have used almost all options and combinations I found on the man emerge, update packages on rev, slot changes, autounmask, complete-graph, backtrack, etc, etc.

Still is just too normal and usual rn that to solve the dependency tree I need to unmerge some packages to finally emerge be able to solve it, from what I see this seems to happens because portage try to not change some slot packages that would cause more rebuilds, but rn ends on just not being solving the tree.

The first issue is that, for some systems we can't solve the tree, rn the only way to fully solve it is with -e, but we does not want that.

We need to remember that be able to build is not the same as solve the tree, usually with enough tests we can build, but skipping packages due to unsolved deps.

This issue also can be related to binhosts, from what I know emerge uses heuristics to solve the tree to avoid solve again from zero. Just for a binhost and their clients is more ideal to the solver be able to get all of them the same result, to keep all the clients consistent between them and the server.

The reason why I request a full_complete_graph features, or similar which should compute the graph from zero instead show a particular case to improve the solver? Is very simple, nothing is perfect, with a issue for a particular case the solver will improve, but there will always cases that the solver will can't handle, and is good have a safe solution for this cases, I think an option like this is great to handle this cases.

Reproducible: Always
Comment 1 Zac Medico gentoo-dev 2024-09-02 18:57:21 UTC
(In reply to Lagu from comment #0)
> We need to remember that be able to build is not the same as solve the tree,
> usually with enough tests we can build, but skipping packages due to
> unsolved deps.

This sounds like bug 328343.
Comment 2 Lagu 2024-10-10 17:35:13 UTC
mm, run emerge in a system with different packages are 10mins, each iteration to solve the dependency tree for package.use and package.accept_keywords, + need to remove all dev-haskell/* packages is really a high amount of time.

Hope this can be implemented early :)
Comment 3 Zac Medico gentoo-dev 2024-10-11 20:16:35 UTC
(In reply to Lagu from comment #0)
> This issue also can be related to binhosts, from what I know emerge uses
> heuristics to solve the tree to avoid solve again from zero. Just for a
> binhost and their clients is more ideal to the solver be able to get all of
> them the same result, to keep all the clients consistent between them and
> the server.

The --rebuilt-binaries option exists to help keep clients consistent with the server.
Comment 4 Lagu 2024-10-11 20:32:03 UTC
Actually I use it, is just that option do not imply that the solution of the clients will be the best from the server options to keep all upgrade.

Heuristics helps a lot, but not in cases where you need some deterministic solutions, like match the solution from the server to the clients.

Just to keep the curiosity, I would say in my experience, the client and server, in the same state, I have reached different upgrade solutions from both.

That option is great, if someone is facing something like this I also agree that use it for today if someone is using a binhost.

The issue https://bugs.gentoo.org/328343 right, is one of the reasons I'm requesting this feature, as a safe feature to be able to solve the dependency tree when things like that happens.

I have faced that issue too, several times.
Comment 5 Lagu 2024-10-11 20:47:57 UTC
Just as a note, when we face upgrade in a more complex system, at least I prefer one big solution, instead try to merge what is able to be upgraded.

My reason is pretty simple, usually when I'm able to finally solve the dependency tree, the upgrade packages are different from the previous solution, which would case to unnecessarily merge too much packages, better solve fine the tree (or most of what can be done), and then upgrade.