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 |