In portage-2.1.11.16 and 2.2.0_alpha127 there’s support for EAPI 5_pre2, which implements all of the features that were approved for EAPI 5 in the Gentoo Council meeting on September 11. The only difference from EAPI 5_pre1 is that the “user patches” feature has been removed.
7 thoughts on “Experimental EAPI 5_pre2”
Comments are closed.
I’m having trouble finding out why user patches didn’t make it into EAPI 5 – could you provide some background? Thank you!
I’ve added a link to the meeting log, so you can see for yourself. Apparently they felt that there was some controversy concerning the specification, and they were also concerned that the existing implementation in portage was only a dummy stub (it was enough to satisfy the spec, but did not actually apply any patches).
Another concern was that user patches would either require an epatch implementation in Portage, or some scheme how Portage can interact with eclasses. Both are non-trivial problems. I’m also not sure if everyone would agree with moving epatch to the PM, where changing it is much harder than in eutils.eclass.
A non-functional stub for user patches wouldn’t have been very helpful for users. What we need is a working implementation.
Seems to me it is all about making things easier for Gentoo maintainers but harder for simple users:
– rejection of user patches
– expand variables are much harder to handle than simple USE, because -VAR not possible
– Profile IUSE injection: What is that, brain fuck? We have use.force already! Why not then trash profiles and just some kind of profile TAG variables, something like
HAVE_AMD64
WANT_KDE
The bad thing about further eapi development is, it is getting harder for the newcomer every day …
They just weren’t happy with the state of the spec. Maybe it will be approved in the next EAPI. Until then, it’s possible to use epatch_user from eutils.eclass.
You can use an empty setting like VAR=”” in make.conf, if you want to disable all of the corresponding flags. You can also do things like USE=”-linguas_en” to disable specific USE_EXPAND flags.
You’re the first person who I’ve seen have a negative reaction to it like that. Maybe you just need to learn more about it in order to appreciate it.
Yes I don’t understand it. But I fear there gets lost a possibility:
I saw there are more ways of Gentoo profiles by looking at “man portage”.
I was thinking about an easy way running Gentoo for simple Desktop users:
LDGD=Lightweight derivative Gentoo Distributions
A simple thread in the forum in conjuntion with a Github repository could be enough to get a go without thinking with Gentoo. Every special Hardware and every special purpose gets a special .git profile and discussion thread, e.g.:
intel-core2-kde
intel-core2-xfce
amd64-kde
etc…
But if Gentoo profiles are now getting hardcoded and mangled with ebuilds this will not be possible any more 🙁
I can assure you that this is not the case. Profile IUSE injection is only intended to be used for very special flags that have global relevance. Ebuilds should still define any other relevant flags in their own IUSE variable.