[gentoo-dev] EAPI 2 policy for portage tree

[Jean-Marc Hengen]

Hi,

I like to write about an observation about gentoo, I made the past 
weeks, which does frustrate me personally a little bit, mainly because 
it makes administration a bit harder for me. It could be considered as 
an issue or as yet another case of "When you play with unstable 
packages, you're on your own.". It's about EAPI 2 and maybe it isn't 
worth changing anything with portage 2.1.6 on the way, but I guess, with 
future EAPI's such a situation could be repeated, so maybe there's 
interest in discussing it. If I'm to late and missed the discussion, I 
apologize for the spam.

This mail is about EAPI usage in the portage tree. Let me describe it, 
with what happened today: I'm running a mostly stable system (91 of 1255 
installed packages are unstable), but I test here and there some 
packages. On of the packages, which I installed and is currently masked 
unstable, is dev-util/cmake-2.6.2. I use it on a daily basis and happy 
with it so far. Today, while updating, portage wanted to downgrade cmake 
to the stable release, due to all cmake 2.6.x version masked by EAPI 2. 
The cmake-2.6.2 ebuild was updated to use EAPI 2 (along with fixing a 
bug). My rule of thumb is to only use unstable on none system packages 
after checking, what can go wrong with the unstable package and if I can 
afford the worst case. Generally I consider portage to be a no-go as 
unstable package. So I'm in the situation, where I used cmake-2.6.2 on a 
daily basis and like to continue, but I can't with the current state of 
tree and my policies (more precisely: I can't keep current stable 
portage and cmake-2.6.2). My solution to the problem, was to copy the 
ebuild in /var/db/pkg to my local overlay and I'm fine with it for now. 
The drawback of this workaround is, I could miss important fixes, like 
security fixes.

This isn't the first issue I had with EAPI 2, but they were until now 
always upgrades to new version or new packages, so I abandoned and 
stayed with the current version or didn't install the package at all and 
wait for stable portage with EAPI 2 support. Up till now I could always 
do without those packages, but if I needed one necessarily, I guess, I 
would have backported the ebuild to a older EAPI, rather than upgrading 
portage. What I don't want to say, is that EAPI 2 should be blocked, 
rather the contrary, I look forward to EAPI 2, but from my perspective, 
in the particular case of cmake described above, I rather had added a 
new revision (cmake-2.6.2-r1) with EAPI 2 and the fix and wouldn't touch 
the cmake-2.6.2 ebuild. This has the advantage, that people with a setup 
like mine can continue to use, what they already use and work on the 
cmake ebuild can continue in the new revision. If the new revision fixes 
a security issue, one can mask the old version, with a message with bug 
telling this. So persons like me know, that they have to decide, what to 
do. Certainly one can have a different approach (like the one, that the 
maintainer of cmake took), which I do accept and what I descriped would 
be my solution.

So this is about, if the current "policy" for using EAPI 2 in the tree 
is really "good" or it should be improved, when introducing future 
EAPI's, where portage supporting that EAPI is still unstable. My 
proposal would be, to only use new EAPI with a new version or revision 
and also let the last non new EAPI version for unstable packages in the 
tree. This would allow users of that unstable package with stable 
portage to not downgrade or maintain their local version or forced to 
upgrade portage. This would be a start.

I guess, I'm not the only one, having such a setup and it prevent user's 
like me testing unstable packages. I need my PC on a daily basis, I 
can't afford, having it to reinstall, only because I played with 
unstable software. That's why I'm strict, when it comes to system 
packages or important packages to me (and I have to congratulate the 
gentoo devs for their work, my system just works like a charm and I'm 
very happy with gentoo, only hardware failures could make me headaches). 
So what I expect, is to find out, if setups like mine can or should be 
somehow supported. I'm fine, when the outcome is, that I won't be 
supported, then I know and should rethink my strategy to manage my 
gentoo boxes.

With kind regards,
Jean-Marc Hengen, a happy gentoo user