When I tried to install =app-emacs/emacs-common-gentoo-1.2-r1 with paludis, it refused due to an EAPI issue: $paludis -qM =app-emacs/emacs-common-gentoo-1.2-r1::gentoo * =app-emacs/emacs-common-gentoo-1.2-r1::gentoo gentoo: (1.2-r1)E* {:(none)} PALUDIS_CHOICES: EBUILD: /gentoo/gentoo-tree/app-emacs/emacs-common-gentoo/emacs-common-gentoo-1.2-r1.ebuild EAPI: -3 Masked by eapi: Unsupported EAPI '-3' On #paludis, ciaranm says that the problem is because the cache in the rsync'd tree was built with an out-of-date portage and should be updated. To check this, I copied the ebuild to a local overlay and re-manifested it with no resulting issues with paludis. Relevant parts of the IRC log on #paludis follows: <ivanm> for some reason, if an ebuild has ` EAPI=3 ' in it, then paludis seems to parse that as having an invalid EAPI of -3 <ivanm> is this the correct behaviour? <ivanm> (note that having ` EAPI="3" ' works) <ciaranm> uh what <ciaranm> no it doesn't <ivanm> paludis -qM =app-emacs/emacs-common-gentoo-1.2-r1::gentoo <ciaranm> paludis doesn't parse ebuilds <ivanm> spits out the following line: <ivanm> Masked by eapi: Unsupported EAPI '-3' <ciaranm> blame portage <ivanm> oh? <ciaranm> the portage version used to generate the metadata shipped with ::gentoo doesn't support EAPI 3 <Ingmar> they ship duff metadata? <ciaranm> when portage doesn't support an EAPI, it writes the metadata cache line with a - in front of it <dvandyk> hahahahaaaaa <ciaranm> you don't see this when using portage because portage always does a cache regen itself for ebuilds with EAPIs it doesn't recognise <ivanm> heh <ciaranm> paludis uses the written metadata instead, and doesn't do a regen <ivanm> ciaranm: so is there any way I can fix this so it doesn't happen to me? <ivanm> (any more) <ciaranm> but when you change the ebuild to add in quotes, you're forcing a regen for paludis too because the timestamps is duff <ciaranm> it's got nothing to do with quotes.... you could equally just touch the ebuild in question
Maybe we should adapt egencache to refrain from generating a cache file if it doesn't know the EAPI of the ebuild. In that case the client just misses the cache and will (re)generat it itself. If the client has a package manager which /does/ support the EAPI it can then just happily continue, be it with degraded performance.
portage has been updated on the master node to 2.1.7.16
The cache generation setup is using portage-2.1.7.17 with EAPI 3 support now.
(In reply to comment #1) > Maybe we should adapt egencache to refrain from generating a cache file if it > doesn't know the EAPI of the ebuild. In that case the client just misses the > cache and will (re)generat it itself. This would cause a performance penalty for versions of portage that don't support EAPI 3, since they'll have to source the ebuild in order to determine the EAPI. As it is, they recognize that EAPI -3 isn't supported and do the right thing with no performance penalty. We can get the best of both worlds if we enable FEATURES=parse-eapi-ebuild-head by default, but it's unreliable unless we mandate it in PMS (with council approval and stuff). > If the client has a package manager > which /does/ support the EAPI it can then just happily continue, be it with > degraded performance. Portage already does that, since it recognizes that EAPI -3 means that the cache needs to be regenerated.
