7 thoughts on “Experimental EAPI 5_pre2

  1. Craig

    I’m having trouble finding out why user patches didn’t make it into EAPI 5 – could you provide some background? Thank you!

    1. zmedico Post author

      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).

      1. Ulrich Müller

        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.

  2. Ralph

    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 …

    1. zmedico Post author

      - rejection of user patches

      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.

      expand variables are much harder to handle than simple USE, because -VAR not possible

      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.

      Profile IUSE injection: What is that, brain fuck? We have use.force already!

      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.

      1. Ralph

        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 :(

        1. zmedico Post author

          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.

Comments are closed.