Hi!
On Thu, 13 Jun 2013 17:41:51 -0500, Mark Hatle <mark.hatle@xxxxxxxxxxxxx> wrote:
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.
Even though I'm not involved with the regular EGLIBC maintenance work (to
keep options groups from breaking, and more), I do have an idea of the
work Joseph has to do with each merge, and can thus fully understand his
proposal to retire them. Also, I too assume that they're not as useful
anymore as they were more than half a decade ago.
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.
How are you suggesting to get information about their usage? And/or, how
would we go about deprecating them?
Are Wind River and the Yocto Project tracking trunk of EGLIBC, or the
latest releases, or even just (slightly) older releases? If not trunk,
removing the support for option groups from trunk right after the
upcoming 2.18 release, for example, would not have any effect
immediatelly for these (presumed) remaining users.