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

Message ID 20170713142549.28078-1-aduskett@gmail.com
State Rejected, archived
Headers show

Commit Message

Adam Duskett July 13, 2017, 2:25 p.m.
currently there are a few packages in buildroot that are set to not
be selectable unless the user wishes to use glibc specifically because
the package uses fts.h.

uClibc actually does have a fts implimentation, and it's selectable in
uclib-menuconfig.  However; this has two issues with it:

1) Most users wouldn't know that there is even a uClibc-menuconfig
2) Even if the user does select fts support in uClibc-menuconfig, the
   packages that would now compile and work would still not be selectable
   because they explicitly require BR2_TOOLCHAIN_USES_GLIBC.

Enabling fts support increases the size of uclibc by 75~kb according to
the menuconfig option.  This is a acceptable size increase to fix the
few packages that require fts.h support.

Signed-off-by: Adam Duskett <aduskett@gmail.com>
---
 package/uclibc/uClibc-ng.config | 1 +
 1 file changed, 1 insertion(+)

Comments

Thomas Petazzoni July 13, 2017, 5:32 p.m. | #1
Hello,

On Thu, 13 Jul 2017 10:25:48 -0400, Adam Duskett wrote:

> Enabling fts support increases the size of uclibc by 75~kb according to

75 KB, or 5-7 KB ?

Thomas
Adam Duskett July 13, 2017, 5:41 p.m. | #2
75KB

On Thu, Jul 13, 2017 at 1:32 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Thu, 13 Jul 2017 10:25:48 -0400, Adam Duskett wrote:
>
>> Enabling fts support increases the size of uclibc by 75~kb according to
>
> 75 KB, or 5-7 KB ?
>
Whoops! My bad.
7.5k according to the menuconfig help.

> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
Thomas Petazzoni July 15, 2017, 9:44 a.m. | #3
Hello,

On Thu, 13 Jul 2017 10:25:48 -0400, Adam Duskett wrote:
> currently there are a few packages in buildroot that are set to not
> be selectable unless the user wishes to use glibc specifically because
> the package uses fts.h.
> 
> uClibc actually does have a fts implimentation, and it's selectable in
> uclib-menuconfig.  However; this has two issues with it:
> 
> 1) Most users wouldn't know that there is even a uClibc-menuconfig
> 2) Even if the user does select fts support in uClibc-menuconfig, the
>    packages that would now compile and work would still not be selectable
>    because they explicitly require BR2_TOOLCHAIN_USES_GLIBC.
> 
> Enabling fts support increases the size of uclibc by 75~kb according to
> the menuconfig option.  This is a acceptable size increase to fix the
> few packages that require fts.h support.
> 
> Signed-off-by: Adam Duskett <aduskett@gmail.com>

Peter, what is your thought on enabling FTS by default in our uClibc-ng
configuration ?

Note that contrary to what Adam commit log says, the size increase is
7.5 KB.

Thanks,

Thomas
Peter Korsgaard July 15, 2017, 3:15 p.m. | #4
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > Hello,
 > On Thu, 13 Jul 2017 10:25:48 -0400, Adam Duskett wrote:
 >> currently there are a few packages in buildroot that are set to not
 >> be selectable unless the user wishes to use glibc specifically because
 >> the package uses fts.h.
 >> 
 >> uClibc actually does have a fts implimentation, and it's selectable in
 >> uclib-menuconfig.  However; this has two issues with it:
 >> 
 >> 1) Most users wouldn't know that there is even a uClibc-menuconfig
 >> 2) Even if the user does select fts support in uClibc-menuconfig, the
 >> packages that would now compile and work would still not be selectable
 >> because they explicitly require BR2_TOOLCHAIN_USES_GLIBC.
 >> 
 >> Enabling fts support increases the size of uclibc by 75~kb according to
 >> the menuconfig option.  This is a acceptable size increase to fix the
 >> few packages that require fts.h support.
 >> 
 >> Signed-off-by: Adam Duskett <aduskett@gmail.com>

 > Peter, what is your thought on enabling FTS by default in our uClibc-ng
 > configuration ?

 > Note that contrary to what Adam commit log says, the size increase is
 > 7.5 KB.

Hmm, 7.5KB isn't much - But fts isn't enabled by default in uClibc-nc,
it is a legacy BSD feature and it also isn't supported by musl.

It is easy to enable uClibc options, but difficult to disable them again
later (as users of the affected packages get caught).

Looking around, it seems we are only talking about 3 packages (if the
annotations are correct):

git grep -l 'fts.h' **/Config.in
package/libcgroup/Config.in
package/libselinux/Config.in
package/libsemanage/Config.in

Do we care enough for selinux users on uClibc (libcgroup seems to only
be an optional dependency for gst1-rtsp-server) to let all other
uClibc-ng users pay?
Adam Duskett July 15, 2017, 5:16 p.m. | #5
Hello;

On Sat, Jul 15, 2017 at 11:15 AM, Peter Korsgaard <peter@korsgaard.com> wrote:
>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
>
>  > Hello,
>  > On Thu, 13 Jul 2017 10:25:48 -0400, Adam Duskett wrote:
>  >> currently there are a few packages in buildroot that are set to not
>  >> be selectable unless the user wishes to use glibc specifically because
>  >> the package uses fts.h.
>  >>
>  >> uClibc actually does have a fts implimentation, and it's selectable in
>  >> uclib-menuconfig.  However; this has two issues with it:
>  >>
>  >> 1) Most users wouldn't know that there is even a uClibc-menuconfig
>  >> 2) Even if the user does select fts support in uClibc-menuconfig, the
>  >> packages that would now compile and work would still not be selectable
>  >> because they explicitly require BR2_TOOLCHAIN_USES_GLIBC.
>  >>
>  >> Enabling fts support increases the size of uclibc by 75~kb according to
>  >> the menuconfig option.  This is a acceptable size increase to fix the
>  >> few packages that require fts.h support.
>  >>
>  >> Signed-off-by: Adam Duskett <aduskett@gmail.com>
>
>  > Peter, what is your thought on enabling FTS by default in our uClibc-ng
>  > configuration ?
>
>  > Note that contrary to what Adam commit log says, the size increase is
>  > 7.5 KB.
>
> Hmm, 7.5KB isn't much - But fts isn't enabled by default in uClibc-nc,
> it is a legacy BSD feature and it also isn't supported by musl.
>
Funny enough, musl's wiki is a bit dated.
http://wiki.musl-libc.org/wiki/FAQ#Q:_why_is_fts.h_not_included_.3F

"if glibc bug 15838 is fixed by adding an fts64 interface in glibc, we could
consider supporting it with a matching ABI in musl, but it seems more likely
that glibc will just deprecate this interface."

The thing is, bug 15838 WAS fixed a while ago, and fts has had a proper
64bit variant for a while.  Not sure why they are dragging their feet, but
that's another topic for another day.


> It is easy to enable uClibc options, but difficult to disable them again
> later (as users of the affected packages get caught).
>
> Looking around, it seems we are only talking about 3 packages (if the
> annotations are correct):
>
> git grep -l 'fts.h' **/Config.in
> package/libcgroup/Config.in
> package/libselinux/Config.in
> package/libsemanage/Config.in
>

True, but why should we deny uClibc users extra security?

> Do we care enough for selinux users on uClibc (libcgroup seems to only
> be an optional dependency for gst1-rtsp-server) to let all other
> uClibc-ng users pay?
>

I have a core-i5, 16 gigs of ram, and a 256gig Crucial MX200 SSD

Build times/sizes with all packages necessary to compile
already download, no compiler cache:

command ran:  time make uclibc

without FTS:

real 7m39.002s
user 15m30.321s
sys 2m6.026s
target: 856k
output/build/uclibc-1.0.25: 51196

with FTS:
real 7m18.378s
user 15m22.944s
sys 2m4.397s
target: 864K
output/build/uclibc-1.0.25: 51244

So, negligable difference in time to compile.
Negligable size difference.
The added benefit of being able to use SELinux, which
allows for better security.

Hardly a payment in my opinion. :)

> --
> Bye, Peter Korsgaard

Thanks!

Adam
Thomas Petazzoni July 15, 2017, 7:48 p.m. | #6
Hello,

On Sat, 15 Jul 2017 17:15:51 +0200, Peter Korsgaard wrote:

>  > Note that contrary to what Adam commit log says, the size increase is
>  > 7.5 KB.  
> 
> Hmm, 7.5KB isn't much - But fts isn't enabled by default in uClibc-nc,
> it is a legacy BSD feature and it also isn't supported by musl.

Agreed.

> It is easy to enable uClibc options, but difficult to disable them again
> later (as users of the affected packages get caught).
> 
> Looking around, it seems we are only talking about 3 packages (if the
> annotations are correct):
> 
> git grep -l 'fts.h' **/Config.in
> package/libcgroup/Config.in
> package/libselinux/Config.in
> package/libsemanage/Config.in
> 
> Do we care enough for selinux users on uClibc (libcgroup seems to only
> be an optional dependency for gst1-rtsp-server) to let all other
> uClibc-ng users pay?

I would personally say no. The driving reason for Adam was to be able
to build the SELinux stuff. But indeed, if you're adding all the
SELinux overhead on your system, you most likely have the filesystem
space needed to switch to glibc.

So I'm fine if we decide to say "no". It should hopefully increase the
pressure on the upstream projects to move away from a legacy BSD
interface, and use the POSIX interface instead.

Best regards,

Thomas
Adam Duskett July 15, 2017, 8:09 p.m. | #7
Hello;

On Sat, Jul 15, 2017 at 3:48 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Sat, 15 Jul 2017 17:15:51 +0200, Peter Korsgaard wrote:
>
>>  > Note that contrary to what Adam commit log says, the size increase is
>>  > 7.5 KB.
>>
>> Hmm, 7.5KB isn't much - But fts isn't enabled by default in uClibc-nc,
>> it is a legacy BSD feature and it also isn't supported by musl.
>
> Agreed.
>
>> It is easy to enable uClibc options, but difficult to disable them again
>> later (as users of the affected packages get caught).
>>
>> Looking around, it seems we are only talking about 3 packages (if the
>> annotations are correct):
>>
>> git grep -l 'fts.h' **/Config.in
>> package/libcgroup/Config.in
>> package/libselinux/Config.in
>> package/libsemanage/Config.in
>>
>> Do we care enough for selinux users on uClibc (libcgroup seems to only
>> be an optional dependency for gst1-rtsp-server) to let all other
>> uClibc-ng users pay?
>
> I would personally say no. The driving reason for Adam was to be able
> to build the SELinux stuff. But indeed, if you're adding all the
> SELinux overhead on your system, you most likely have the filesystem
> space needed to switch to glibc.
>
Not only that, but as stated in the past, uClibc-ng is the default
toolchain for buildroot.  And as it sits, even if somebody did go in and
turn fts on in uclibc-ng, they still wouldn't be able to select the SELinux
packages.

> So I'm fine if we decide to say "no". It should hopefully increase the
> pressure on the upstream projects to move away from a legacy BSD
> interface, and use the POSIX interface instead.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
Peter Korsgaard July 16, 2017, 3:53 p.m. | #8
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > Hello,
 > On Sat, 15 Jul 2017 17:15:51 +0200, Peter Korsgaard wrote:

 >> > Note that contrary to what Adam commit log says, the size increase is
 >> > 7.5 KB.  
 >> 
 >> Hmm, 7.5KB isn't much - But fts isn't enabled by default in uClibc-nc,
 >> it is a legacy BSD feature and it also isn't supported by musl.

 > Agreed.

 >> It is easy to enable uClibc options, but difficult to disable them again
 >> later (as users of the affected packages get caught).
 >> 
 >> Looking around, it seems we are only talking about 3 packages (if the
 >> annotations are correct):
 >> 
 >> git grep -l 'fts.h' **/Config.in
 >> package/libcgroup/Config.in
 >> package/libselinux/Config.in
 >> package/libsemanage/Config.in
 >> 
 >> Do we care enough for selinux users on uClibc (libcgroup seems to only
 >> be an optional dependency for gst1-rtsp-server) to let all other
 >> uClibc-ng users pay?

 > I would personally say no. The driving reason for Adam was to be able
 > to build the SELinux stuff. But indeed, if you're adding all the
 > SELinux overhead on your system, you most likely have the filesystem
 > space needed to switch to glibc.

 > So I'm fine if we decide to say "no". It should hopefully increase the
 > pressure on the upstream projects to move away from a legacy BSD
 > interface, and use the POSIX interface instead.

Ok, agreed. Adam, sorry but we prefer to keep things as they
are. It should be fairly easy for uClibc-ng users wanting to enable
selinux to notice that they need to change to glibc instead based on the
comment:

comment "libselinux needs a glibc toolchain w/ threads, dynamic library"
Waldemar Brodkorb July 16, 2017, 4:43 p.m. | #9
Hi Peter, Thomas,
Peter Korsgaard wrote,

> >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> 
>  > Hello,
>  > On Sat, 15 Jul 2017 17:15:51 +0200, Peter Korsgaard wrote:
> 
>  >> > Note that contrary to what Adam commit log says, the size increase is
>  >> > 7.5 KB.  
>  >> 
>  >> Hmm, 7.5KB isn't much - But fts isn't enabled by default in uClibc-nc,
>  >> it is a legacy BSD feature and it also isn't supported by musl.
> 
>  > Agreed.
> 
>  >> It is easy to enable uClibc options, but difficult to disable them again
>  >> later (as users of the affected packages get caught).
>  >> 
>  >> Looking around, it seems we are only talking about 3 packages (if the
>  >> annotations are correct):
>  >> 
>  >> git grep -l 'fts.h' **/Config.in
>  >> package/libcgroup/Config.in
>  >> package/libselinux/Config.in
>  >> package/libsemanage/Config.in
>  >> 
>  >> Do we care enough for selinux users on uClibc (libcgroup seems to only
>  >> be an optional dependency for gst1-rtsp-server) to let all other
>  >> uClibc-ng users pay?
> 
>  > I would personally say no. The driving reason for Adam was to be able
>  > to build the SELinux stuff. But indeed, if you're adding all the
>  > SELinux overhead on your system, you most likely have the filesystem
>  > space needed to switch to glibc.
> 
>  > So I'm fine if we decide to say "no". It should hopefully increase the
>  > pressure on the upstream projects to move away from a legacy BSD
>  > interface, and use the POSIX interface instead.
> 
> Ok, agreed. Adam, sorry but we prefer to keep things as they
> are. It should be fairly easy for uClibc-ng users wanting to enable
> selinux to notice that they need to change to glibc instead based on the
> comment:
> 
> comment "libselinux needs a glibc toolchain w/ threads, dynamic library"

But this is not the case, they don't need to switch to glibc.
The decision makes me sad, as it goes the opposite way I try to
develop in Buildroot. I added a lot of stuff f.e. to uClibc-ng to
allow to build and use systemd. The required systemd patches are
upstream. I regulary try to enable packages which are disabled for no
good reason for uClibc users. AutoFS next version will contain the
patch allowing to use uClibc-ng and libtirpc instead of Glibc.

And what about the people using an architecture which is not supported
by glibc? Like Sparc, ARC, Xtensa and Or1k? Or the no-MMU
architectures? 

We enabled Wordexp recently and I would really love to see this
enabled, too. Could you rethink about your decision?

best regards
 Waldemar
Adam Duskett July 16, 2017, 5:40 p.m. | #10
All;

On Sun, Jul 16, 2017 at 12:43 PM, Waldemar Brodkorb <wbx@openadk.org> wrote:
> Hi Peter, Thomas,
> Peter Korsgaard wrote,
>
>> >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
>>
>>  > Hello,
>>  > On Sat, 15 Jul 2017 17:15:51 +0200, Peter Korsgaard wrote:
>>
>>  >> > Note that contrary to what Adam commit log says, the size increase is
>>  >> > 7.5 KB.
>>  >>
>>  >> Hmm, 7.5KB isn't much - But fts isn't enabled by default in uClibc-nc,
>>  >> it is a legacy BSD feature and it also isn't supported by musl.
>>
>>  > Agreed.
>>
>>  >> It is easy to enable uClibc options, but difficult to disable them again
>>  >> later (as users of the affected packages get caught).
>>  >>
>>  >> Looking around, it seems we are only talking about 3 packages (if the
>>  >> annotations are correct):
>>  >>
>>  >> git grep -l 'fts.h' **/Config.in
>>  >> package/libcgroup/Config.in
>>  >> package/libselinux/Config.in
>>  >> package/libsemanage/Config.in
>>  >>
>>  >> Do we care enough for selinux users on uClibc (libcgroup seems to only
>>  >> be an optional dependency for gst1-rtsp-server) to let all other
>>  >> uClibc-ng users pay?
>>
>>  > I would personally say no. The driving reason for Adam was to be able
>>  > to build the SELinux stuff. But indeed, if you're adding all the
>>  > SELinux overhead on your system, you most likely have the filesystem
>>  > space needed to switch to glibc.
>>
>>  > So I'm fine if we decide to say "no". It should hopefully increase the
>>  > pressure on the upstream projects to move away from a legacy BSD
>>  > interface, and use the POSIX interface instead.
>>
>> Ok, agreed. Adam, sorry but we prefer to keep things as they
>> are. It should be fairly easy for uClibc-ng users wanting to enable
>> selinux to notice that they need to change to glibc instead based on the
>> comment:
>>
>> comment "libselinux needs a glibc toolchain w/ threads, dynamic library"
But that's simply not true.  uClibc-ng compiles it just fine if FTS is
turned on.
>
> But this is not the case, they don't need to switch to glibc.
> The decision makes me sad, as it goes the opposite way I try to
> develop in Buildroot. I added a lot of stuff f.e. to uClibc-ng to
> allow to build and use systemd. The required systemd patches are
> upstream. I regulary try to enable packages which are disabled for no
> good reason for uClibc users. AutoFS next version will contain the
> patch allowing to use uClibc-ng and libtirpc instead of Glibc.
>
> And what about the people using an architecture which is not supported
> by glibc? Like Sparc, ARC, Xtensa and Or1k? Or the no-MMU
> architectures?
>
This is also a good point.  Why would we deny uClibc-ng users security?
Glibc has a large history of CVE's:
https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-767/GNU-Glibc.html

uClibc is smaller and thus has a smaller attack vector, which is good
in conjuntion
with SELinux.

> We enabled Wordexp recently and I would really love to see this
> enabled, too. Could you rethink about your decision?
>
> best regards
>  Waldemar

Thanks!

Adam
Yann E. MORIN July 16, 2017, 6:46 p.m. | #11
Adam, Waldemar, All,

On 2017-07-16 13:40 -0400, Adam Duskett spake thusly:
> On Sun, Jul 16, 2017 at 12:43 PM, Waldemar Brodkorb <wbx@openadk.org> wrote:
> > Peter Korsgaard wrote,
> >> >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
[--SNIP--]
> >>  > So I'm fine if we decide to say "no". It should hopefully increase the
> >>  > pressure on the upstream projects to move away from a legacy BSD
> >>  > interface, and use the POSIX interface instead.
> >>
> >> Ok, agreed. Adam, sorry but we prefer to keep things as they
> >> are. It should be fairly easy for uClibc-ng users wanting to enable
> >> selinux to notice that they need to change to glibc instead based on the
> >> comment:
> >>
> >> comment "libselinux needs a glibc toolchain w/ threads, dynamic library"
> But that's simply not true.  uClibc-ng compiles it just fine if FTS is
> turned on.

I can see two issues there:

  - fts() is deprecated, obsoleted; it is not POSIX:
        http://pubs.opengroup.org/onlinepubs/9699919799/idx/if.html

  - external toolchain, uClibc-based: since fts is a deprecated
    interface, it is most probably that an external toolchain does not
    have it.

Besides, musl does not provide it, so the SELinux stuff is anyway not
avbailable to everyone.

People interested in having SELinux with non-glibc will have to provide
a patch against SELinux to be dsure they are usable, at least with musl,
which is a C library with good momentum.

[--SNIP--]
> > And what about the people using an architecture which is not supported
> > by glibc? Like Sparc, ARC, Xtensa and Or1k? Or the no-MMU
> > architectures?

*This* is a valid reason to add fts() to our internal uClibc
configuraiton. If anythong, this should be the only argument exposed to
add fts().

> This is also a good point.  Why would we deny uClibc-ng users security?
> Glibc has a large history of CVE's:
> https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-767/GNU-Glibc.html
> 
> uClibc is smaller and thus has a smaller attack vector, which is good

But unfortunately, uClibc-ng has far less exposure than glibc, so this
is also a security concern...

> in conjuntion
> with SELinux.
> 
> > We enabled Wordexp recently and I would really love to see this
> > enabled, too. Could you rethink about your decision?

I was initially writing this mail to argue in favour of adding fts(),
and now I am a little bit more suspicious, too. The only killing
argument for me is the one about archs without a glibc port. Those are
left out in the cold, and that's not nice...

Regards,
Yann E. MORIN.
Arnout Vandecappelle July 18, 2017, 7:24 p.m. | #12
On 16-07-17 18:43, Waldemar Brodkorb wrote:
> Hi Peter, Thomas,
> Peter Korsgaard wrote,
[snip]
>> Ok, agreed. Adam, sorry but we prefer to keep things as they
>> are. It should be fairly easy for uClibc-ng users wanting to enable
>> selinux to notice that they need to change to glibc instead based on the
>> comment:
>>
>> comment "libselinux needs a glibc toolchain w/ threads, dynamic library"
> 
> But this is not the case, they don't need to switch to glibc.
> The decision makes me sad, as it goes the opposite way I try to
> develop in Buildroot.

 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 added a lot of stuff f.e. to uClibc-ng to
> allow to build and use systemd. The required systemd patches are
> upstream. I regulary try to enable packages which are disabled for no
> good reason for uClibc users. AutoFS next version will contain the
> patch allowing to use uClibc-ng and libtirpc instead of Glibc.

 Patching packages so they work with uClibc is important too, but not relevant
to this discussion. Although indeed possibly the better option would be to patch
those four packages to avoid fts.h. But as written earlier: that's not so trivial.


> And what about the people using an architecture which is not supported
> by glibc? Like Sparc, ARC, Xtensa and Or1k? Or the no-MMU
> architectures? 
> 
> We enabled Wordexp recently and I would really love to see this
> enabled, too. Could you rethink about your decision?

 wordexp is different because it's actually POSIX. IMO our default uClibc config
should cover all of POSIX.


 Regards,
 Arnout
Thomas Petazzoni July 18, 2017, 9:06 p.m. | #13
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.

Best regards,

Thomas
Waldemar Brodkorb July 18, 2017, 9:07 p.m. | #14
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.

best regards
 Waldemar
Alexey Brodkin Oct. 12, 2017, 1:06 a.m. | #15
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
Thomas Petazzoni Oct. 12, 2017, 7:52 a.m. | #16
Hello,

On Thu, 12 Oct 2017 01:06:32 +0000, Alexey Brodkin wrote:

> 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.

Well, we want to provide a user experience that is reasonable for
newcomers, and therefore if a package depends on a uClibc feature that
our default uClibc configuration doesn't enable, the only easy solution
is to add a "depends on !uclibc" or "depends on glibc".

The other options would be:

 * Do not add a dependency. We would get tons of build failures
   reported in the autobuilders, and the results of the autobuilders
   would become unreadable. Our newcomer users would face weird build
   failures when they enable a new package, definitely not the
   experience we want for newcomers.

 * Add more and more Buildroot options to replicate the myriad of
   uClibc configuration options. But then how do we test all of this ?
   Who is going to try and test all the weird combinations ?

> 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.

IPv6 was enable because tons and tons of packages now assume that IPv6
is supported by the C library. We had gazillions of packages that had a
dependency on IPv6.

FTS on the other hand is only needed by very few packages:

 - clamav has fanotify functionality disabled because of this

 - elfutils, but we have worked around this by adding a custom fts
   implementation as a patch

 - libcgroup

 - libselinux/libsemanage

 - a few ltp-testsuite tests, but the biggest part of ltp-testsuite is
   OK.

And that's pretty much it. As you can see, the case for enabling FTS
by default is a lot weaker than the case for enabling IPv6.

> 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.

Yes, I agree that there is a balance between "purity" and "pragmatism".

I don't have a very strong opinion on this FTS enabled or not. I don't
remember the size measurements with FTS enabled/disabled. Perhaps we
should just enable all features needed by Buildroot packages in our
uClibc configuration.

Best regards,

Thomas
Waldemar Brodkorb Oct. 12, 2017, 6:08 p.m. | #17
Hi,
Thomas Petazzoni wrote,

> > 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.
> 
> Yes, I agree that there is a balance between "purity" and "pragmatism".
> 
> I don't have a very strong opinion on this FTS enabled or not. I don't
> remember the size measurements with FTS enabled/disabled. Perhaps we
> should just enable all features needed by Buildroot packages in our
> uClibc configuration.

That would be indeed the best policy!

And I don't think a lot is missing. May be just FTS!

best regards
 Waldemar
Adam Duskett Oct. 12, 2017, 6:56 p.m. | #18
Just throwing my two cents in again:




If uClibc is the default c library, denying users the ability to use SELinux isn't very nice.  Even more so when going to uclibc-menuconfig and enabling fts.h still doesn't allow them to enable it. 




The more devices that use SELinux the better in my opinion.









On Thu, Oct 12, 2017 at 2:08 PM -0400, "Waldemar Brodkorb" <wbx@openadk.org> wrote:










Hi,
Thomas Petazzoni wrote,

> > 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.
> 
> Yes, I agree that there is a balance between "purity" and "pragmatism".
> 
> I don't have a very strong opinion on this FTS enabled or not. I don't
> remember the size measurements with FTS enabled/disabled. Perhaps we
> should just enable all features needed by Buildroot packages in our
> uClibc configuration.

That would be indeed the best policy!

And I don't think a lot is missing. May be just FTS!

best regards
 Waldemar
<html><head></head><body><div dir="auto" style="direction: ltr; margin: 0; padding: 0; font-family: sans-serif; font-size: 11pt; color: black; background-color: white;">Just throwing my two cents in again:<br>
<br>
</div>
<div dir="auto" style="direction: ltr; margin: 0; padding: 0; font-family: sans-serif; font-size: 11pt; color: black; background-color: white;">If uClibc is the default c library, denying users the ability to use SELinux isn't very nice.&nbsp; Even more so when going to uclibc-menuconfig and enabling fts.h still doesn't allow them to enable it. <br>
<br>
</div>
<div dir="auto" style="direction: ltr; margin: 0; padding: 0; font-family: sans-serif; font-size: 11pt; color: black; background-color: white;">The more devices that use SELinux the better in my opinion.<br>
</div>
<div dir="auto" style="direction: ltr; margin: 0; padding: 0; font-family: sans-serif; font-size: 11pt; color: black; background-color: white;"><br>
</div>
<br><br><br>
<div class="gmail_quote">On Thu, Oct 12, 2017 at 2:08 PM -0400, "Waldemar Brodkorb" <span dir="ltr">&lt;<a href="mailto:wbx@openadk.org" target="_blank">wbx@openadk.org</a>&gt;</span> wrote:<br>
<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div dir="3D&quot;ltr&quot;">
<pre>Hi,
Thomas Petazzoni wrote,

&gt; &gt; 3. Regarding purity of standards I may agree that we as more knowledgeable
&gt; &gt; &nbsp; &nbsp;engineers need to educate our users and resist temptation to return to
&gt; &gt; &nbsp; &nbsp;deprecated things. But as an advocate of my users I'd say that usability
&gt; &gt; &nbsp; &nbsp;and support of wider packages might be even more important.
&gt; 
&gt; Yes, I agree that there is a balance between "purity" and "pragmatism".
&gt; 
&gt; I don't have a very strong opinion on this FTS enabled or not. I don't
&gt; remember the size measurements with FTS enabled/disabled. Perhaps we
&gt; should just enable all features needed by Buildroot packages in our
&gt; uClibc configuration.

That would be indeed the best policy!

And I don't think a lot is missing. May be just FTS!

best regards
 Waldemar
</pre>
</div>

</blockquote>
</div>
</body></html>
Alexey Brodkin Oct. 13, 2017, 4:59 p.m. | #19
Hi Thomas,

On Thu, 2017-10-12 at 20:08 +0200, Waldemar Brodkorb wrote:
> Hi,

> Thomas Petazzoni wrote,

> 

> > 

> > > 

> > > 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.

> > 

> > Yes, I agree that there is a balance between "purity" and "pragmatism".

> > 

> > I don't have a very strong opinion on this FTS enabled or not. I don't

> > remember the size measurements with FTS enabled/disabled. Perhaps we

> > should just enable all features needed by Buildroot packages in our

> > uClibc configuration.

> 

> That would be indeed the best policy!

> 

> And I don't think a lot is missing. May be just FTS!


Well there might be more things but still I'd prefer to enable more
packages by default if it doesn't affect entire system (especially with
those "special" packages not enabled) a lot.

I mean as long as we don't introduce significant increase of either
memory footprint of existing system or cause run-time overhead it's
good to allow more packages to be built.

That said if someone wants more stripped down system it's easier
to disable uClibc options (directly via uclibc-menuconfig) compared
to:
 a) Enabling extra options in uClibc plus
 b) Patch Buildroot
to get some extra packages.

-Alexey

Patch

diff --git a/package/uclibc/uClibc-ng.config b/package/uclibc/uClibc-ng.config
index 5beb2bd90..3a3a15fa3 100644
--- a/package/uclibc/uClibc-ng.config
+++ b/package/uclibc/uClibc-ng.config
@@ -33,6 +33,7 @@  UCLIBC_HAS_GLIBC_CUSTOM_STREAMS=y
 UCLIBC_HAS_PRINTF_M_SPEC=y
 UCLIBC_HAS_WORDEXP=y
 UCLIBC_HAS_NFTW=y
+UCLIBC_HAS_FTS=y
 UCLIBC_HAS_FTW=y
 UCLIBC_HAS_GNU_GLOB=y
 RUNTIME_PREFIX="/"