Hi Michał,

Michał Górny <mgo...@gentoo.org> writes:

>> I am on the toolchain alias, and I am interested in joining the project.
>> I will be responsible to deal with all the bugs for glibc-2.16 and
>> glibc-2.19.  Bug wranglers' work load does not change.
>> 
>> Yes, I apologize this will generate some noise for toolchain@g.o.  But I
>> anticipate people on the team are interested in receiving those emails.
>
> That's not a solution. That's cheap a cheap excuse that works for one
> package, for today. It does not solve the generic case,

What I ask is a special treatment of glibc.  I do not intend to explore
a generic solution in this thread.  And don't get me wrong, I support
tree cleaning by all means.

Glibc is special, llvm is the only other (not so similar) example.  No
more package will be special like this.  This will not set a bad example
or bad excuses for keeping outdated ebuilds.  I don't see your argument
of generic case.

> it does not mean that other members of toolchain or any other team
> will not end up having to remember extra rules like 'do not remove
> this ebuild because X wants it'.

Is that a problem?  When at least 1 person is eager to maintain an
package, the package could be kept.  Consider that person as the de
facto upstream.

Consider glibc-2.16 as a sys-libs/glibc-revived package that is too
closely connected to sys-libs/glibc be treated as a 2nd package.  Then
the package argument carries to a special version of ebuild.

Cheers,
Benda

Reply via email to