[Patches] Any remaining uses of option groups?

["Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>]

My previous message removing a bitrotten and ill-conceived option group 
<http://www.eglibc.org/archives/patches/msg01257.html> did not elicit any 
responses expressing interest in option groups at all.  So, I now ask: 
does anyone have a current use case for the option groups feature?  That 
is, is there still any significant use of EGLIBC in building new embedded 
GNU/Linux systems that are so space-constrained that the few MB taken up 
by all the EGLIBC shared libraries put together is so significant that the 
limited proportion of that space that can be saved through option groups 
actually matters?

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.

The same applies to the changes to make --disable-versioning work: 
although those don't add complexity in the same way, --disable-versioning 
is also an option to make a small space gain at the expense of breaking 
ABI compatibility with the default configuration.  So it may well be the 
case that removing --disable-versioning from glibc (and so from EGLIBC) 
would be better than merging the --disable-versioning fixes to glibc.

My suggestion regarding both of the above is that space-saving 
configuration options are only now appropriate where they change neither 
API nor ABI (so it's still reasonable to be able to eliminate some of the 
IFUNC variants of a function, for example, as that doesn't affect the 
public user interface).  Other things can already be removed by the user 
at the whole-file level without needing any special configuration support 
(e.g. locales or gconv modules).

An underlying principle here: I have long considered there to be a 
distinction between EGLIBC the project to enhance glibc for embedded 
systems, and EGLIBC the separate source tree.  The goal of enhancing 
embedded system support (meaning embedded systems being built now, rather 
than those of 2006) can now be fulfilled in the context of the glibc 
source tree.  The separate source tree was a workaround for former 
dysfunction in glibc development.  That reason for its existence no longer 
exists, and the remaining use of the separate source tree is now (a) to 
hold residual changes relative to glibc, as listed at 
<http://www.eglibc.org/archives/patches/msg01261.html>, until those 
features can be merged into glibc in some form, and (b) a few bits of 
compatibility code to help existing EGLIBC users where e.g. a makefile 
variable name changed in the course of merging a feature into glibc.

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.

-- 
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx
_______________________________________________
Patches mailing list
Patches@xxxxxxxxxx
http://eglibc.org/cgi-bin/mailman/listinfo/patches