1 |
On Mon, Feb 26, 2018 at 12:22 PM, William Hubbs <williamh@g.o> wrote: |
2 |
|
3 |
> On Sun, Feb 25, 2018 at 10:10:26AM +0100, Michał Górny wrote: |
4 |
> > W dniu nie, 25.02.2018 o godzinie 15∶17 +0900, użytkownik Benda Xu |
5 |
> > napisał: |
6 |
> > > Hi all, |
7 |
> > > |
8 |
> > > Yes, it's 2018. But there are still RHEL 4 and 5 systems running |
9 |
> > > antique kernels such as 2.6.8 and 2.6.18. In my experience, many of |
10 |
> > > them are data acquisition hubs or computing clusters. No administrator |
11 |
> > > cares about security as long as they "work". |
12 |
> > > |
13 |
> > > Under the form "Prefix", Gentoo is set out to rescue users trapped in |
14 |
> > > these abandoned wastelands of antiques. After years of work, we have |
15 |
> > > achieved that goal, except one minor thing: glibc periodically drop |
16 |
> > > support for old linux kernels, the lastest glibc supporting linux 2.6.8 |
17 |
> > > is 2.16 and for linux-2.6.18 it is glibc-2.19. |
18 |
> > > |
19 |
> > > With the recent reunion of the Toolchain Project, old glibc versions |
20 |
> are |
21 |
> > > masked and removed, accelerating the adoption of new versions. This |
22 |
> > > opens a new oppotunity for the Prefix: people stops caring about |
23 |
> > > unsupported glibc versions, the Prefix Project can take them over |
24 |
> > > without worrying about breaking other peoples' machines. |
25 |
> > > |
26 |
> > > Now, profiles/default/linux/amd64/17.0/no-multilib/prefix/ |
27 |
> kernel-2.6.16+ |
28 |
> > > unmasks <glibc-2.18. Some pathes needs to be backported, like the |
29 |
> > > /lib/gentoo/functions.sh transition. prefix/kernel-2.6+ with |
30 |
> glibc-2.16 |
31 |
> > > is also planned. In addition, glibc have to be patched to get python3 |
32 |
> > > built[1-3], which is urgent once portage drops python2[4]. |
33 |
> > > |
34 |
> > > |
35 |
> > > So I would like to hear what you guys think if I: |
36 |
> > > |
37 |
> > > - keep glibc-2.19 and glibc-2.16 in tree and unmasking them in the |
38 |
> > > selected Prefix profiles; |
39 |
> > > |
40 |
> > > - maintain those selected outdated glibc versions on the |
41 |
> > > infrastructure of the Toolchain Project[5]; |
42 |
> > > |
43 |
> > > - (optional) add an exception to the toolchain support policy[6]. |
44 |
> > |
45 |
> > |
46 |
> > How about moving them to an overlay? |
47 |
> |
48 |
> I am with mgorny on this, this sort of specialized support does not |
49 |
> belong in the main tree. |
50 |
|
51 |
|
52 |
So I actually originally thought this as well and settled on some logic |
53 |
that is: |
54 |
|
55 |
The problem we are trying to solve is supporting very old distros. This has |
56 |
two impacts on the tree: |
57 |
a) Very old versions of some packages stay in the tree because they are |
58 |
needed to support these old platforms. |
59 |
b) Very old versions of some packages will need to drop keywords for |
60 |
'rolling' platforms. E.g. I'd expect glibc-really-old to be keyworded only |
61 |
for 'prefix' but not for 'x86' or 'amd64'. This is because the latter two |
62 |
are not well tested[1] |
63 |
|
64 |
A and B are both mostly about control and maintenance of the tree itself |
65 |
(these do not necessarily reflect the quality or stability of prefix as a |
66 |
platform.) |
67 |
|
68 |
The separate problem is: |
69 |
Given some prefix users are running prefix on these old platforms, how do |
70 |
we detect when support for them breaks (as it did for py3, and will again |
71 |
in the future when something else critical breaks.) I'm curious to hear |
72 |
more about this process, but I think its orthogonal to in-tree or |
73 |
in-overlay support; other than the overlay gives you more control over when |
74 |
to release / withdraw various package versions (more control than just |
75 |
keywords do in the main tree.) |
76 |
|
77 |
Note that Gentoo itself purports to offer only 1 year of support for the |
78 |
main tree; so just based on that axiom alone I think trying to support 10+ |
79 |
year old platforms goes against what the main-tree is targeting. |
80 |
|
81 |
-A |
82 |
|
83 |
|
84 |
> The kernel versions you are talking about aren't even supported by the |
85 |
> upstream kernel folks any more -- the oldest lts version is 3.2.99. |
86 |
> |
87 |
> Thanks, |
88 |
> |
89 |
> William |
90 |
> |
91 |
> |