Hi William and Alec, Yes, I hear you.
What I want to do is not randomly throwing upstream-unmaintained package versions into Gentoo tree. But the opposite, 1 specially maintained glibc ebuild serving as a compatible layer will isolate the obsolete linux kernel from the modern Gentoo tree. Synonymically, 1 glibc ebuild will allow the rest of the Gentoo tree compile and run on 10+ years old platforms. The users trapped with antique OS will be able to use tools from Gentoo, and Gentoo will expand its horizon for new use cases. Detailed replies inline, mostly repeating of the above point for special cases. William Hubbs <willi...@gentoo.org> writes: > I am with mgorny on this, this sort of specialized support does not > belong in the main tree. > > The kernel versions you are talking about aren't even supported by the > upstream kernel folks any more -- the oldest lts version is 3.2.99. I am with you. I don't care about outdated kernels. Therefore I am interested in a compatible layer that screens out the kernel. So far, 1 glibc does the job. Alec Warner <anta...@gentoo.org> writes: > So I actually originally thought this as well and settled on some > logic that is: > > The problem we are trying to solve is supporting very old > distros. This has two impacts on the tree: > a) Very old versions of some packages stay in the tree because they > are needed to support these old platforms. s/some packages/1 glibc ebuild/ The concerned package is only 1 version of glibc per a group of kernels, no more. It is well-contained, not a can of worms. > b) Very old versions of some packages will need to drop keywords for > 'rolling' platforms. E.g. I'd expect glibc-really-old to be keyworded > only for 'prefix' but not for 'x86' or 'amd64'. To clarify, prefix-standalone uses implicit keyword scheme, the same usual keywords as 'amd64'. We could mask the old versions as the status quo. > This is because the latter two are not well tested[1] > > A and B are both mostly about control and maintenance of the tree > itself (these do not necessarily reflect the quality or stability of > prefix as a platform.) > > The separate problem is: > Given some prefix users are running prefix on these old platforms, how > do we detect when support for them breaks (as it did for py3, and will > again in the future when something else critical breaks.) We can require each platform (or profile) to have at least 1 dev as an active user, for example: https://wiki.gentoo.org/wiki/Project:Prefix#Platform_matrix Recently, I have found an ultimate solution to the python3 puzzle. Usually, glibc exposes all the symbols it supports. Whether the kernel supports the symbols are determined at runtime. But, if the glibc is patched to be faithful to the kernels it is running on, python3 happily compiles and runs. And yes, we know exactly what kernels are expected, e.g. glibc-2.16 for linux-2.6 ~ 2.6.15. Therefore we have a define goal to patch the glibc. By this strategy, even RHEL4 runs python-3.6 well. > I'm curious to hear more about this process, but I think its > orthogonal to in-tree or in-overlay support; other than the overlay > gives you more control over when to release / withdraw various package > versions (more control than just keywords do in the main tree.) Note > that Gentoo itself purports to offer only 1 year of support for the > main tree; so just based on that axiom alone I think trying to support > 10+ year old platforms goes against what the main-tree is targeting. Again, a glibc ebuild isolates the antique kernel and all the dirty work of supporting 10+ year old platform is absorbed in 1 ebuild. Therefore the 1-year-of-support model of Gentoo tree is not violated and untouched. Hope that address the concerns of potential degradation of our main tree quality. Cheers, Benda
signature.asc
Description: PGP signature
