[Buildroot] [PATCH 1/2] uclibc-ng: enable fts in default config file.

[Alexey Brodkin <Alexey.Brodkin@synopsys.com>]

Hi Thomas, Waldemar, Arnout, all,

On Tue, 2017-07-18 at 23:07 +0200, Waldemar Brodkorb wrote:
> Hi,
> Thomas Petazzoni wrote,
> 
> > 
> > Hello,
> > 
> > On Tue, 18 Jul 2017 21:24:05 +0200, Arnout Vandecappelle wrote:
> > 
> > > 
> > > ?I'm with you on this one. If a package can work with uClibc, we really should
> > > allow it.
> > > 
> > > ?However, I don't think the solution is to bloat our default uClibc config with
> > > features that are not useful for 99.82% of our packages. fts.h is not something
> > > like IPv6 that is useful for a large number of packages.
> > > 
> > > ?I also don't think we should add more options like BR2_ENABLE_LOCALE that copy
> > > the uClibc config options.
> > > 
> > > ?Perhaps the way to go is to have a BR2_TOOLCHAIN_UCLIBC_BLOAT_CONFIG option
> > > that a user can set to indicate he wants to see packages that will not work with
> > > our default uClibc config. That option could give a nice warning that this
> > > configuration is not tested and YMMV.
> > 
> > I have to say I don't like this. If we have an option, it should work,
> > and therefore be tested. It's the worst thing for users to simply tick
> > an option, and discover build failures here and there. If you have an
> > option that explicitly allows to do something, then that something
> > should work.
> 
> I still don't get it.
> We are not trying to disable fts in glibc, so it is available there.
> Why we can't enable it for uClibc-ng to get more compatibility?
> Just because of the bigger size?
> 
> If someone needs a really small system, there is always the
> possibilty to use a really small uClibc-ng config.

Sorry for bumping that stale thread - unintentionally bumped into it
so here're my 2 cents.

1. As a representative of those minorities who's been living without glibc
? ?I'm a bit disappointed to see those packages that "depends on *GLIBC*"
? ?especially if that's just a matter of config option in some tool.
? ?BTW it's not very obvious that "make uclibc-menucofig" may help here,
? ?also inevitably user will need to patch Buildroot removing
? ?"depends on BR2_TOOLCHAIN_USES_GLIBC" to get desired stuff built.
? ?That said for an experienced people like we are it's a piece of cake
? ?while for newcomers who only expect to toggle options in Buildroot's
? ?xconfig (i.e. with mouse in nice GUI) it will be a roadblock.

2. Speaking about bloating of default uClibc config in Buildroot I think
? ?we saw movements from both sides but in the same direction:
? ? - uClibc's options get removed or become enabled by default to make it
? ? ? simpler, cleaner and more robust tool but that inevitable adds a couple
? ? ? of hundred bytes here and there. I haven't done comparison of uClibc
? ? ? sizes from release to release, but might be Waldemar has some data here.
? ? - Buildroot's add-ons to uClibc's defaults also were adding more and more
? ? ? things [and some unconditionally]. For example IPv6 is always on now while
? ? ? I guess this option adds quite a bit of size.

? ? So I think yet another minor option being enabled won't be a problem.

3. Regarding purity of standards I may agree that we as more knowledgeable
? ?engineers need to educate our users and resist temptation to return to
? ?deprecated things. But as an advocate of my users I'd say that usability
? ?and support of wider packages might be even more important.
? ?In the end glibc developers and users couldn't care less about users of
? ?musl and uClibc if glibc legacy causes issues to named minorities as well
? ?as they are not?courageously getting rid of that legacy knowing it will
? ?really break applications used by many-many people.

-Alexey