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

Reply via email to