| 1 |
Hi Andreas, |
| 2 |
|
| 3 |
"Andreas K. Huettel" <dilfridge@g.o> writes: |
| 4 |
|
| 5 |
> Well, in principle the idea is OK. We already/still keep some old |
| 6 |
> glibc, gcc, and binutils versions for that reason. |
| 7 |
> |
| 8 |
> However, I have a few conditions. |
| 9 |
> |
| 10 |
> * Only masked. Only prefix keywords. |
| 11 |
|
| 12 |
Not problem for masking. For keywords, prefix-standalone uses usual |
| 13 |
keywords, not prefix keywords. |
| 14 |
|
| 15 |
https://wiki.gentoo.org/wiki/Project:Prefix/Technical_Documentation#Search_pathes |
| 16 |
|
| 17 |
> If you really must unmask them in a specific prefix profile, you must |
| 18 |
> provide big fat warnings about the resulting security risks. (I dont |
| 19 |
> know how things went in prehistoric times, but recently there have |
| 20 |
> been a LOT of glibc-related CVEs. Many fixes can be backported, but |
| 21 |
> definitely not all of them.) |
| 22 |
|
| 23 |
Yes, I think that's the way to go to keep users reminded of security |
| 24 |
risks involved. |
| 25 |
|
| 26 |
> * No toolchain-glibc.eclass or eblits or similar abominations. Standard QA |
| 27 |
> rules apply. |
| 28 |
|
| 29 |
Agreed! Old glibc becomes a burden for toolchain-glibc.eclass |
| 30 |
maintenance. We'd better make them standalone. |
| 31 |
|
| 32 |
> * Try to stick to a minimum of required features (and a minimum of required |
| 33 |
> versions). |
| 34 |
> We want to strongly avoid adding conditionals to other packages. [#] |
| 35 |
|
| 36 |
Sure, the feature set will be kept bare minimal. For example, handened |
| 37 |
patches will be removed. |
| 38 |
|
| 39 |
> * Please use our gentoo glibc repo to keep track of branches and patchsets. |
| 40 |
> Happy to show you the details sometime soon. |
| 41 |
|
| 42 |
Thanks Andreas. Much appreciated. |
| 43 |
|
| 44 |
> [#] If not for such "old version" considerations, we could soon move the |
| 45 |
> libtirpc headers to the place where the glibc headers used to live. That could |
| 46 |
> save us a ...load of patching and bugfixing. By keeping flexibility and |
| 47 |
> compatibility, that is unfortunately not possible. |
| 48 |
|
| 49 |
That's where I see providing glibc-2.16 and 2.19 in special profiles |
| 50 |
might shed light on this delimma. We keep versions of glibc to make |
| 51 |
sure some old systems do not break. But those systems are not clearly |
| 52 |
defined. We don't have a guideline for when and how to remove them. |
| 53 |
(We used to keep them almost indefinitely before the reformation of |
| 54 |
toolchain project.) |
| 55 |
|
| 56 |
By explicitly spelling out the range of kernels a specific glibc |
| 57 |
supports, and only keeping the minimal set of old versions, the |
| 58 |
boundaries are defined. |
| 59 |
|
| 60 |
Cheers, |
| 61 |
Benda |
Archives