| 1 |
Hi Michał,
|
| 2 |
|
| 3 |
Michał Górny <mgorny@g.o> writes:
|
| 4 |
|
| 5 |
>> I am on the toolchain alias, and I am interested in joining the project. |
| 6 |
>> I will be responsible to deal with all the bugs for glibc-2.16 and |
| 7 |
>> glibc-2.19. Bug wranglers' work load does not change. |
| 8 |
>> |
| 9 |
>> Yes, I apologize this will generate some noise for toolchain@g.o. But I |
| 10 |
>> anticipate people on the team are interested in receiving those emails. |
| 11 |
> |
| 12 |
> That's not a solution. That's cheap a cheap excuse that works for one |
| 13 |
> package, for today. It does not solve the generic case, |
| 14 |
|
| 15 |
What I ask is a special treatment of glibc. I do not intend to explore
|
| 16 |
a generic solution in this thread. And don't get me wrong, I support
|
| 17 |
tree cleaning by all means.
|
| 18 |
|
| 19 |
Glibc is special, llvm is the only other (not so similar) example. No
|
| 20 |
more package will be special like this. This will not set a bad example
|
| 21 |
or bad excuses for keeping outdated ebuilds. I don't see your argument
|
| 22 |
of generic case.
|
| 23 |
|
| 24 |
> it does not mean that other members of toolchain or any other team |
| 25 |
> will not end up having to remember extra rules like 'do not remove |
| 26 |
> this ebuild because X wants it'. |
| 27 |
|
| 28 |
Is that a problem? When at least 1 person is eager to maintain an
|
| 29 |
package, the package could be kept. Consider that person as the de
|
| 30 |
facto upstream.
|
| 31 |
|
| 32 |
Consider glibc-2.16 as a sys-libs/glibc-revived package that is too
|
| 33 |
closely connected to sys-libs/glibc be treated as a 2nd package. Then
|
| 34 |
the package argument carries to a special version of ebuild.
|
| 35 |
|
| 36 |
Cheers,
|
| 37 |
Benda |
Archives