Hi Andreas, "Andreas K. Huettel" <dilfri...@gentoo.org> writes:
> Well, in principle the idea is OK. We already/still keep some old > glibc, gcc, and binutils versions for that reason. > > However, I have a few conditions. > > * Only masked. Only prefix keywords. Not problem for masking. For keywords, prefix-standalone uses usual keywords, not prefix keywords. https://wiki.gentoo.org/wiki/Project:Prefix/Technical_Documentation#Search_pathes > If you really must unmask them in a specific prefix profile, you must > provide big fat warnings about the resulting security risks. (I dont > know how things went in prehistoric times, but recently there have > been a LOT of glibc-related CVEs. Many fixes can be backported, but > definitely not all of them.) Yes, I think that's the way to go to keep users reminded of security risks involved. > * No toolchain-glibc.eclass or eblits or similar abominations. Standard QA > rules apply. Agreed! Old glibc becomes a burden for toolchain-glibc.eclass maintenance. We'd better make them standalone. > * Try to stick to a minimum of required features (and a minimum of required > versions). > We want to strongly avoid adding conditionals to other packages. [#] Sure, the feature set will be kept bare minimal. For example, handened patches will be removed. > * Please use our gentoo glibc repo to keep track of branches and patchsets. > Happy to show you the details sometime soon. Thanks Andreas. Much appreciated. > [#] If not for such "old version" considerations, we could soon move the > libtirpc headers to the place where the glibc headers used to live. That > could > save us a ...load of patching and bugfixing. By keeping flexibility and > compatibility, that is unfortunately not possible. That's where I see providing glibc-2.16 and 2.19 in special profiles might shed light on this delimma. We keep versions of glibc to make sure some old systems do not break. But those systems are not clearly defined. We don't have a guideline for when and how to remove them. (We used to keep them almost indefinitely before the reformation of toolchain project.) By explicitly spelling out the range of kernels a specific glibc supports, and only keeping the minimal set of old versions, the boundaries are defined. Cheers, Benda
signature.asc
Description: PGP signature
