[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Patches] Any remaining uses of option groups?

On 6/13/13 5:12 PM, Joseph S. Myers wrote:

On Thu, 13 Jun 2013, Mark Hatle wrote:


I suspect that option groups are an idea whose time is past: that the
space constraints that were relevant when option groups were added six and
a half years ago are not the space constraints that are relevant today,
that today's embedded GNU/Linux systems have vastly more software than was
usual then, and that any residual use for the feature is outweighed by the
extra complexity it introduces, the combinatorial explosion of different
feature combinations, mostly untested and likely broken, and the extra
difficulty it adds to merges from glibc.  Thus, I think it may well be
time to remove this feature, and with it the vast bulk of the divergence
from glibc.


I think they are still useful, but I agree.  The usage of them is diminishing


You're saying you agree that the cost now outweighs the benefit and it's
time to remove the feature (whether before 2.18, or after 2.18 branches)
rather than to attempt to get some form of it into glibc?
I agree that the use of them is diminishing. I don't think it's time to remove them yet. But maybe in another 6 months to a year we'll have more information. It's the 32-bit microcontroller like systems that would still need this. If they prove to not be an issue, then I don't have a problem with removing them. 


If you care about some some or all of the residual areas of difference, I
strongly encourage you to join in the process of merging patches to glibc
so the areas you care about cease to be differences between the two trees
at all and the separate tree can be made obsolete for you.  Active glibc
development means that differences between the two trees are quite likely
to become bitrotten in EGLIBC over time without someone actively watching
them and testing in those areas.


The two patches I care about right now (that I'm aware of) are the option
groups and the 'ldconfig'/'ldd' to not require bash.  For the former, I don't
have much insight into how invasive they are.  For the later, the patches were
submitted -- and I know there is a pending action to get these submitted to
the regular glibc group.  I believe the only thing preventing it right now is
some type of copyright assignment.


The option groups are by far the most invasive change of the 17 listed
areas of difference.  (Some cross-localedef changes are quite invasive ...
At this point I'm inclined to say that option groups do NOT get merged to glibc proper, unless someone can justify doing the work. However, I do still believe they will be useful and something that can be justified as being a patch maintained on top of glibc. (With the belief that the patch will either prove to be valuable in the 6 month to 1 year time frame, or it will be abandoned at not useful.) 


there I wonder if the support for non-glibc hosts or hosts with too-old
glibc could be killed, replacing the special cross-localedef build with
the ability to do a normal native glibc build that produces a localedef
binary that can also build locales for other systems.)  For ldd, we need
The cross-localedef patches I thought had already been merged. Yes, those are definitely things we want. 


P. J. McDermott to complete the copyright assignment process for the
patches posted to libc-alpha in November 2012; getting that sorted out
should allow making progress on eliminating ldd as an area of divergence.
I know Peter Seebach also submitted a set, but I don't believe they went anywhere either. 

--Mark

_______________________________________________
Patches mailing list
Patches@xxxxxxxxxx
http://eglibc.org/cgi-bin/mailman/listinfo/patches