Gentoo Archives: gentoo-dev

From: Jean-Marc Hengen <gentoo@××××××××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] EAPI 2 policy for portage tree
Date: Mon, 08 Dec 2008 23:57:45
1 Hi,
3 I like to write about an observation about gentoo, I made the past
4 weeks, which does frustrate me personally a little bit, mainly because
5 it makes administration a bit harder for me. It could be considered as
6 an issue or as yet another case of "When you play with unstable
7 packages, you're on your own.". It's about EAPI 2 and maybe it isn't
8 worth changing anything with portage 2.1.6 on the way, but I guess, with
9 future EAPI's such a situation could be repeated, so maybe there's
10 interest in discussing it. If I'm to late and missed the discussion, I
11 apologize for the spam.
13 This mail is about EAPI usage in the portage tree. Let me describe it,
14 with what happened today: I'm running a mostly stable system (91 of 1255
15 installed packages are unstable), but I test here and there some
16 packages. On of the packages, which I installed and is currently masked
17 unstable, is dev-util/cmake-2.6.2. I use it on a daily basis and happy
18 with it so far. Today, while updating, portage wanted to downgrade cmake
19 to the stable release, due to all cmake 2.6.x version masked by EAPI 2.
20 The cmake-2.6.2 ebuild was updated to use EAPI 2 (along with fixing a
21 bug). My rule of thumb is to only use unstable on none system packages
22 after checking, what can go wrong with the unstable package and if I can
23 afford the worst case. Generally I consider portage to be a no-go as
24 unstable package. So I'm in the situation, where I used cmake-2.6.2 on a
25 daily basis and like to continue, but I can't with the current state of
26 tree and my policies (more precisely: I can't keep current stable
27 portage and cmake-2.6.2). My solution to the problem, was to copy the
28 ebuild in /var/db/pkg to my local overlay and I'm fine with it for now.
29 The drawback of this workaround is, I could miss important fixes, like
30 security fixes.
32 This isn't the first issue I had with EAPI 2, but they were until now
33 always upgrades to new version or new packages, so I abandoned and
34 stayed with the current version or didn't install the package at all and
35 wait for stable portage with EAPI 2 support. Up till now I could always
36 do without those packages, but if I needed one necessarily, I guess, I
37 would have backported the ebuild to a older EAPI, rather than upgrading
38 portage. What I don't want to say, is that EAPI 2 should be blocked,
39 rather the contrary, I look forward to EAPI 2, but from my perspective,
40 in the particular case of cmake described above, I rather had added a
41 new revision (cmake-2.6.2-r1) with EAPI 2 and the fix and wouldn't touch
42 the cmake-2.6.2 ebuild. This has the advantage, that people with a setup
43 like mine can continue to use, what they already use and work on the
44 cmake ebuild can continue in the new revision. If the new revision fixes
45 a security issue, one can mask the old version, with a message with bug
46 telling this. So persons like me know, that they have to decide, what to
47 do. Certainly one can have a different approach (like the one, that the
48 maintainer of cmake took), which I do accept and what I descriped would
49 be my solution.
51 So this is about, if the current "policy" for using EAPI 2 in the tree
52 is really "good" or it should be improved, when introducing future
53 EAPI's, where portage supporting that EAPI is still unstable. My
54 proposal would be, to only use new EAPI with a new version or revision
55 and also let the last non new EAPI version for unstable packages in the
56 tree. This would allow users of that unstable package with stable
57 portage to not downgrade or maintain their local version or forced to
58 upgrade portage. This would be a start.
60 I guess, I'm not the only one, having such a setup and it prevent user's
61 like me testing unstable packages. I need my PC on a daily basis, I
62 can't afford, having it to reinstall, only because I played with
63 unstable software. That's why I'm strict, when it comes to system
64 packages or important packages to me (and I have to congratulate the
65 gentoo devs for their work, my system just works like a charm and I'm
66 very happy with gentoo, only hardware failures could make me headaches).
67 So what I expect, is to find out, if setups like mine can or should be
68 somehow supported. I'm fine, when the outcome is, that I won't be
69 supported, then I know and should rethink my strategy to manage my
70 gentoo boxes.
72 With kind regards,
73 Jean-Marc Hengen, a happy gentoo user


Subject Author
Re: [gentoo-dev] EAPI 2 policy for portage tree "Olivier Crête" <tester@g.o>
Re: [gentoo-dev] EAPI 2 policy for portage tree "Robert R. Russell" <nahoy_kbiki@××××××××.com>
Re: [gentoo-dev] EAPI 2 policy for portage tree "Jan Kundrát" <jkt@g.o>