On 8 November 2014 05:40, Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > On Fri, 07 Nov 2014 20:57:41 +0100 > Jauhien Piatlicki <jauh...@gentoo.org> 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.)
