Re: [gentoo-dev] Portage dependency solving algorithm

[Hilco Wijbenga]

On 8 November 2014 05:40, Ciaran McCreesh
<ciaran.mccreesh@××××××××××.com> wrote:
> On Fri, 07 Nov 2014 20:57:41 +0100
> Jauhien Piatlicki <jauhien@g.o> wrote:
>> What;s wrong with input? PMS itself or how do maintainers write
>> ebuilds? Could you explain?
>
> A mixture of both. Gentoo developers like writing eclasses that write
> unnecessarily clever, highly messy and technically incorrect dependency
> strings (see how Perl and Ruby are done, for prime examples). Doing
> this kind of thing well requires support from PMS, so developers can
> express what they want to say directly rather than via some convoluted
> mess of nested ||s, []s, slot abuse and faked range dependencies.
> However, it's currently culturally more acceptable to try to make
> yourself look clever by writing the new "world's most convoluted family
> of eclasses", so developers aren't asking for the features they need.
>
> In a way, this brings us back to SAT and CNF. Although you *can* encode
> this kind of thing in SAT (or rather, in QSAT...), the encoding is
> utterly opaque and doesn't lend itself to a good algorithm. The
> dependencies some developers are writing are nearly as bad.

So would it make sense then to move to a more declarative ebuild
model? Or just a "better" model?

Both Portage and Paludis at some point figure out what they think is
needed to install an ebuild. At that point, they could emit an ebuild
in a "new and improved" model? I have no doubt that this scheme would
fail utterly for many of the more complex/convoluted ebuilds but if it
worked for, say, 80% then the work to improve the tree would be
drastically reduced.

(I only write the simplest of ebuilds so I'm undoubtedly
oversimplifying but I thought I would throw this idea out there.)