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
