Gentoo Archives: gentoo-server

From: "José González Gómez" <jgonzalez.openinput@×××××.com>
To: gentoo-server@l.g.o
Subject: [gentoo-server] Stable portage tree (again)
Date: Wed, 06 Sep 2006 08:26:40
Message-Id: 306bf010609060121w41f74fbdpcb4acd37a279654b@mail.gmail.com
1 Hi there,
2
3 >From time to time a thread regarding this ad GLEP 19 shows in the list. I've
4 been thinking about the problem, and would like to share my thoughts, and
5 hear other's people comments:
6
7 First of all, instability of the portage tree may be caused, or better,
8 perceived for two reasons: addition of new ebuilds (maybe under tested) and
9 deletion of old ebuilds (not longer supported by the Gentoo team).
10
11 About the first point, addition of new ebuilds, some people perceive the
12 addition per se as a source of instability, but I think this comes from the
13 "emerge -uDN world" kind of sys admining. As long as you stick with a stable
14 set of versions for your packages, and use glsa-check for doing secutiry
15 upgrades, you would have a slowly changing system you can have under
16 control. Then once a year or two you may go the emerge world way, and have a
17 system totally upgraded with the latest available versions. Or even better,
18 you may gradually update your applications to control the upgrade pace. In
19 addition, what's stable for a given admin or installation may be completely
20 broken for some other admin or installation, so I don't see a real benefit
21 of having a ultra-stable branch of ebuilds, also taking into account that
22 those ebuilds should be tested with all the available use flags combination
23 to really be sure they're really stable. I think we can't ask the Gentoo
24 devs for this, it's insane. I think a better approach for this would be to
25 have a kind of wiki web hosted at whatever.gentoo.org, where admins would
26 report their success/failure using a given version of a package with a given
27 set of use flags. Then you could take your own informed decission before
28 ever trying to upgrade to a new version in your test environment (you have
29 one, don't you?)
30
31 About the deletion of ebuilds, this is another kind of beast, that can cause
32 problems while upgrading, revdep-rebuilding, reverting to older versions in
33 case of problematic upgrades... I guess the reason to delete an ebuild is
34 that the Gentoo devs no longer support them and this is the explicit way of
35 telling it. So let's imagine I still want to use that ebuild knowing I'll be
36 on my own, what options do I have? Maybe getting an old snapshot, checking
37 out an old revision from the Gentoo cvs (is this publicly available?) or
38 hand mantaining my own portage tree.
39
40 I would like to make a proposal here. What if no longer mantained ebuilds
41 were marked but not deleted? Let's say you have _x86 in KEYWORDS for
42 ebuilds/packages no longer mantained, that emerge is aware of that and can
43 inform us of this and that those ebuilds are mantained in the portage tree
44 for, let's say, a year WITH NO SECURITY BACKPORTS on them. This would be
45 kind of a end of life notice that gives you some time to react. This way you
46 still would be able to use the ebuild at your own risk, and this wouldn't
47 represent much extra work load for the Gentoo devs, as the deletion process
48 could be automatic with the use of some scripts. What do you think?
49
50 Best regards
51 Jose

Replies

Subject Author
Re: [gentoo-server] Stable portage tree (again) "paul kölle" <pkoelle@×××××.com>
Re: [gentoo-server] Stable portage tree (again) Tomek Lutelmowski <tomek@×××××.pl>
Re: [gentoo-server] Stable portage tree (again) Alex Efros <powerman@××××××××××××××××××.com>
Re: [gentoo-server] Stable portage tree (again) Andrew Cowie <andrew@×××××××××××××××××××.com>