1 |
Hi William and Alec, |
2 |
|
3 |
Yes, I hear you. |
4 |
|
5 |
What I want to do is not randomly throwing upstream-unmaintained package |
6 |
versions into Gentoo tree. But the opposite, 1 specially maintained |
7 |
glibc ebuild serving as a compatible layer will isolate the obsolete |
8 |
linux kernel from the modern Gentoo tree. Synonymically, 1 glibc ebuild |
9 |
will allow the rest of the Gentoo tree compile and run on 10+ years old |
10 |
platforms. |
11 |
|
12 |
The users trapped with antique OS will be able to use tools from Gentoo, |
13 |
and Gentoo will expand its horizon for new use cases. |
14 |
|
15 |
Detailed replies inline, mostly repeating of the above point for special |
16 |
cases. |
17 |
|
18 |
William Hubbs <williamh@g.o> writes: |
19 |
|
20 |
> I am with mgorny on this, this sort of specialized support does not |
21 |
> belong in the main tree. |
22 |
> |
23 |
> The kernel versions you are talking about aren't even supported by the |
24 |
> upstream kernel folks any more -- the oldest lts version is 3.2.99. |
25 |
|
26 |
I am with you. I don't care about outdated kernels. Therefore I am |
27 |
interested in a compatible layer that screens out the kernel. So far, 1 |
28 |
glibc does the job. |
29 |
|
30 |
Alec Warner <antarus@g.o> writes: |
31 |
|
32 |
> So I actually originally thought this as well and settled on some |
33 |
> logic that is: |
34 |
> |
35 |
> The problem we are trying to solve is supporting very old |
36 |
> distros. This has two impacts on the tree: |
37 |
|
38 |
> a) Very old versions of some packages stay in the tree because they |
39 |
> are needed to support these old platforms. |
40 |
|
41 |
s/some packages/1 glibc ebuild/ |
42 |
|
43 |
The concerned package is only 1 version of glibc per a group of kernels, |
44 |
no more. It is well-contained, not a can of worms. |
45 |
|
46 |
> b) Very old versions of some packages will need to drop keywords for |
47 |
> 'rolling' platforms. E.g. I'd expect glibc-really-old to be keyworded |
48 |
> only for 'prefix' but not for 'x86' or 'amd64'. |
49 |
|
50 |
To clarify, prefix-standalone uses implicit keyword scheme, the same |
51 |
usual keywords as 'amd64'. We could mask the old versions as the status |
52 |
quo. |
53 |
|
54 |
> This is because the latter two are not well tested[1] |
55 |
> |
56 |
> A and B are both mostly about control and maintenance of the tree |
57 |
> itself (these do not necessarily reflect the quality or stability of |
58 |
> prefix as a platform.) |
59 |
> |
60 |
> The separate problem is: |
61 |
|
62 |
> Given some prefix users are running prefix on these old platforms, how |
63 |
> do we detect when support for them breaks (as it did for py3, and will |
64 |
> again in the future when something else critical breaks.) |
65 |
|
66 |
We can require each platform (or profile) to have at least 1 dev as an |
67 |
active user, for example: |
68 |
|
69 |
https://wiki.gentoo.org/wiki/Project:Prefix#Platform_matrix |
70 |
|
71 |
Recently, I have found an ultimate solution to the python3 puzzle. |
72 |
Usually, glibc exposes all the symbols it supports. Whether the kernel |
73 |
supports the symbols are determined at runtime. But, if the glibc is |
74 |
patched to be faithful to the kernels it is running on, python3 happily |
75 |
compiles and runs. And yes, we know exactly what kernels are expected, |
76 |
e.g. glibc-2.16 for linux-2.6 ~ 2.6.15. Therefore we have a define goal |
77 |
to patch the glibc. |
78 |
|
79 |
By this strategy, even RHEL4 runs python-3.6 well. |
80 |
|
81 |
> I'm curious to hear more about this process, but I think its |
82 |
> orthogonal to in-tree or in-overlay support; other than the overlay |
83 |
> gives you more control over when to release / withdraw various package |
84 |
> versions (more control than just keywords do in the main tree.) Note |
85 |
> that Gentoo itself purports to offer only 1 year of support for the |
86 |
> main tree; so just based on that axiom alone I think trying to support |
87 |
> 10+ year old platforms goes against what the main-tree is targeting. |
88 |
|
89 |
Again, a glibc ebuild isolates the antique kernel and all the dirty work |
90 |
of supporting 10+ year old platform is absorbed in 1 ebuild. Therefore |
91 |
the 1-year-of-support model of Gentoo tree is not violated and |
92 |
untouched. |
93 |
|
94 |
Hope that address the concerns of potential degradation of our main tree |
95 |
quality. |
96 |
|
97 |
Cheers, |
98 |
Benda |