Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 841206 - sys-apps/portage support for external CUDF solvers
Summary: sys-apps/portage support for external CUDF solvers
Status: UNCONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-04-27 00:02 UTC by Alessandro Barbieri
Modified: 2022-07-02 18:10 UTC (History)
3 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 Alessandro Barbieri 2022-04-27 00:02:48 UTC
It would be nice (and a major improvement) to have portage offload the dependency calculation to a solver compatible with the CUDF format http://www.mancoosi.org/cudf/
for example
aspcud https://potassco.org/aspcud/
packup http://sat.inesc-id.pt/~mikolas/sw/packup/
mccs http://www.i3s.unice.fr/~cpjm/misc/mccs.html
p2Cudf https://wiki.eclipse.org/Equinox/p2/CUDFResolver
Comment 1 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2022-04-27 06:51:36 UTC
Is the format capable of expressing subslot-induced rebuilds?
Comment 2 Alessandro Barbieri 2022-05-03 22:46:32 UTC
No, not directly. Maybe portage can scan the list of the packages to be installed and add to that list the packages to be rebuilt
Comment 3 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-05-19 01:30:39 UTC
FWIW, https://wiki.eclipse.org/Equinox/p2/CUDFResolver at least says "The input and output format is CUDF. This format has been designed by the Mancoosi European project to foster improvements in dependency resolution solvers. Supporting a different format can be done trivially, just contact us."
Comment 4 Adel KARA SLIMANE 2022-07-02 11:26:19 UTC
I went on and read the CUDF specification [1] and I do not see right away what kind of transformation we could do to be able to handle everything related to USE flags (e.g. user defined toggles, use dependencies), let's take use dependencies: 

There is an entry called 'provides' that indicate what a package provides once installed. Which looks like the only thing that can fit with use flags, one maybe can do something like this

package: www-client/firefox
provides: www-client/firefox-[flag1] www-client/firefox-[flag2] ...

So basically to prepend the flag name with the package name to make the name unique and referenceable.

A few issues:

- It looks like we cannot write dependencies based on stuff written in "provides"
- Even if we could, so other packages can refer to www-client/firefox-[flag_i] in their dependency string to express a use dependency. But afaik once the package is installed it provides ALL of the things listed there. So if another package conflicts with a specific flag in `www-client/firefox` (a possible use dependency). Then the package simply cannot be installed at all.

Or maybe I didn't spend enough time thinking to figure out how to map Gentoo's dependency problem to CUDF.

CUDF seems to fit well only with binary distributions, it probably needs the attention of Gentoo devs to think this through and make an extension proposal to the format, so we can use it. Maybe I will be able to contribute to that, in the near future.


[1] https://www.mancoosi.org/reports/tr3.pdf
Comment 5 Alessandro Barbieri 2022-07-02 18:10:40 UTC
(In reply to Adel KARA SLIMANE from comment #4)
> I went on and read the CUDF specification [1] and I do not see right away
> what kind of transformation we could do to be able to handle everything
> related to USE flags (e.g. user defined toggles, use dependencies), let's
> take use dependencies: 
> 
> There is an entry called 'provides' that indicate what a package provides
> once installed. Which looks like the only thing that can fit with use flags,
> one maybe can do something like this
> 
> package: www-client/firefox
> provides: www-client/firefox-[flag1] www-client/firefox-[flag2] ...
> 
> So basically to prepend the flag name with the package name to make the name
> unique and referenceable.
> 

Try this

package: www-client/firefox-[flag1]
provides: www-client/firefox

package: www-client/firefox-[flag2]
provides: www-client/firefox

> A few issues:
> 
> - It looks like we cannot write dependencies based on stuff written in
> "provides"

From [1]

package: battery
version: 3
provides: huge-battery
installed: true

package: electric-engine
version: 1
depends: solar-collector | huge-battery
provides: engine
conflicts:engine, electric-engine

> [1] https://www.mancoosi.org/reports/tr3.pdf