| Message ID | 20170713142549.28078-1-aduskett@gmail.com |
|---|---|
| State | Rejected, archived |
| Headers | show |
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
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
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
>>>>> "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?
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
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
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
>>>>> "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"
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
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
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.
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
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
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
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
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
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
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. 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"><<a href="mailto:wbx@openadk.org" target="_blank">wbx@openadk.org</a>></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"ltr""> <pre>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 </pre> </div> </blockquote> </div> </body></html>
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
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="/"
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(+)