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

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

[Adam Duskett]

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(+)

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="/"
-- 
2.13.0

[Buildroot] [PATCH 2/2] selinux packages: change glibc check to musl check

[Adam Duskett]

As per the previous patch, now that fts support is enabled by,
default for uClibc, the selinux packages can compile by default
with uClibc and glibc.

Signed-off-by: Adam Duskett <aduskett@gmail.com>
---
 package/checkpolicy/Config.in                      |  6 ++--
 package/libselinux/Config.in                       |  8 +++---
 package/libsemanage/Config.in                      |  8 +++---
 package/policycoreutils/Config.in                  | 12 ++++----
 package/refpolicy/0001-fix-fallthrough-error.patch | 32 ++++++++++++++++++++++
 package/refpolicy/Config.in                        |  6 ++--
 package/setools/Config.in                          |  6 ++--
 7 files changed, 55 insertions(+), 23 deletions(-)
 create mode 100644 package/refpolicy/0001-fix-fallthrough-error.patch

diff --git a/package/checkpolicy/Config.in b/package/checkpolicy/Config.in
index 97ad0b770..7d16ef14a 100644
--- a/package/checkpolicy/Config.in
+++ b/package/checkpolicy/Config.in
@@ -2,7 +2,7 @@ config BR2_PACKAGE_CHECKPOLICY
 	bool "checkpolicy"
 	depends on BR2_TOOLCHAIN_HAS_THREADS # libselinux
 	depends on !BR2_STATIC_LIBS # libselinux
-	depends on BR2_TOOLCHAIN_USES_GLIBC # libselinux
+	depends on !BR2_TOOLCHAIN_USES_MUSL # libselinux
 	depends on !BR2_arc # libselinux
 	select BR2_PACKAGE_LIBSELINUX
 	select BR2_PACKAGE_FLEX
@@ -15,7 +15,7 @@ config BR2_PACKAGE_CHECKPOLICY
 
 	  http://selinuxproject.org/page/Main_Page
 
-comment "checkpolicy needs a glibc toolchain w/ threads, dynamic library"
+comment "checkpolicy needs a uClibc or glibc toolchain w/ threads, dynamic library"
 	depends on !BR2_arc
 	depends on !BR2_TOOLCHAIN_HAS_THREADS || BR2_STATIC_LIBS || \
-		!BR2_TOOLCHAIN_USES_GLIBC
+		BR2_TOOLCHAIN_USES_MUSL
diff --git a/package/libselinux/Config.in b/package/libselinux/Config.in
index 6be816db7..746ba4907 100644
--- a/package/libselinux/Config.in
+++ b/package/libselinux/Config.in
@@ -2,8 +2,8 @@ config BR2_PACKAGE_LIBSELINUX
 	bool "libselinux"
 	depends on BR2_TOOLCHAIN_HAS_THREADS
 	depends on !BR2_STATIC_LIBS
-	# Uses <fts.h>, not available in musl or uClibc
-	depends on BR2_TOOLCHAIN_USES_GLIBC
+	# Uses <fts.h>, not available in musl
+	depends on BR2_TOOLCHAIN_USES_MUSL
 	# Toolchain issue: "fixup not contained within frag"
 	depends on !BR2_arc
 	select BR2_PACKAGE_LIBSEPOL
@@ -19,7 +19,7 @@ config BR2_PACKAGE_LIBSELINUX
 
 	  http://selinuxproject.org/page/Main_Page
 
-comment "libselinux needs a glibc toolchain w/ threads, dynamic library"
+comment "libselinux needs a uClibc or glibc toolchain w/ threads, dynamic library"
 	depends on !BR2_arc
 	depends on !BR2_TOOLCHAIN_HAS_THREADS || BR2_STATIC_LIBS || \
-		!BR2_TOOLCHAIN_USES_GLIBC
+		BR2_TOOLCHAIN_USES_MUSL
diff --git a/package/libsemanage/Config.in b/package/libsemanage/Config.in
index 7ee9c3860..3ab9c36c4 100644
--- a/package/libsemanage/Config.in
+++ b/package/libsemanage/Config.in
@@ -3,10 +3,10 @@ config BR2_PACKAGE_LIBSEMANAGE
 	depends on BR2_PACKAGE_AUDIT_ARCH_SUPPORTS
 	depends on BR2_TOOLCHAIN_HAS_THREADS
 	depends on !BR2_STATIC_LIBS
-	# - libselinux needs fts.h (not available in uClibc/musl)
+	# - libselinux needs fts.h (not available in musl)
 	# - libsemanage itself needs getpwent_r() not available in musl
 	# - audit is not available on musl
-	depends on BR2_TOOLCHAIN_USES_GLIBC
+	depends on !BR2_TOOLCHAIN_USES_MUSL
 	depends on !BR2_arc
 	select BR2_PACKAGE_AUDIT
 	select BR2_PACKAGE_LIBSELINUX
@@ -23,8 +23,8 @@ config BR2_PACKAGE_LIBSEMANAGE
 
 	  http://selinuxproject.org/page/Main_Page
 
-comment "libsemanage needs a glibc toolchain w/ threads, dynamic library"
+comment "libsemanage needs a uClibc or glibc toolchain w/ threads, dynamic library"
 	depends on !BR2_arc
 	depends on BR2_PACKAGE_AUDIT_ARCH_SUPPORTS
 	depends on !BR2_TOOLCHAIN_HAS_THREADS || BR2_STATIC_LIBS || \
-		!BR2_TOOLCHAIN_USES_GLIBC
+		BR2_TOOLCHAIN_USES_MUSL
diff --git a/package/policycoreutils/Config.in b/package/policycoreutils/Config.in
index 6b58d6ea3..7f71ebeba 100644
--- a/package/policycoreutils/Config.in
+++ b/package/policycoreutils/Config.in
@@ -1,7 +1,7 @@
-comment "policycoreutils needs a glibc toolchain w/ threads, dynamic library"
+comment "policycoreutils needs a uClibc or glibc toolchain w/ threads, dynamic library"
 	depends on !BR2_arc
 	depends on BR2_PACKAGE_AUDIT_ARCH_SUPPORTS
-	depends on !BR2_TOOLCHAIN_USES_GLIBC || \
+	depends on BR2_TOOLCHAIN_USES_MUSL || \
 		!BR2_TOOLCHAIN_HAS_THREADS || BR2_STATIC_LIBS
 
 config BR2_PACKAGE_POLICYCOREUTILS
@@ -10,7 +10,7 @@ config BR2_PACKAGE_POLICYCOREUTILS
 	depends on BR2_TOOLCHAIN_HAS_THREADS # libsemanage
 	depends on !BR2_STATIC_LIBS #libsemanage
 	depends on !BR2_arc # libsemanage
-	depends on BR2_TOOLCHAIN_USES_GLIBC # libsemanage
+	depends on !BR2_TOOLCHAIN_USES_MUSL # libsemanage
 	select BR2_PACKAGE_LIBSEMANAGE
 	select BR2_PACKAGE_LIBCAP_NG
 	help
@@ -51,7 +51,7 @@ config BR2_PACKAGE_POLICYCOREUTILS_AUDIT2ALLOW
 	depends on BR2_USE_MMU # python3, sepolgen
 	depends on BR2_TOOLCHAIN_HAS_THREADS # python3, sepolgen, checkpolicy
 	depends on !BR2_STATIC_LIBS # python3, sepolgen
-	depends on BR2_TOOLCHAIN_USES_GLIBC # checkpolicy
+	depends on !BR2_TOOLCHAIN_USES_MUSL # checkpolicy
 	depends on !BR2_arc # checkpolicy
 	select BR2_PACKAGE_SEPOLGEN
 	select BR2_PACKAGE_CHECKPOLICY
@@ -59,11 +59,11 @@ config BR2_PACKAGE_POLICYCOREUTILS_AUDIT2ALLOW
 	help
 	  Enable audit2allow to be built
 
-comment "audit2allow needs a glibc toolchain w/ wchar, threads, dynamic library"
+comment "audit2allow needs a uClibc or glibc toolchain w/ wchar, threads, dynamic library"
 	depends on BR2_USE_MMU
 	depends on !BR2_arc
 	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS || \
-		BR2_STATIC_LIBS
+		BR2_STATIC_LIBS || BR2_TOOLCHAIN_USES_MUSL
 
 config BR2_PACKAGE_POLICYCOREUTILS_RESTORECOND
 	bool "restorecond"
diff --git a/package/refpolicy/Config.in b/package/refpolicy/Config.in
index 954dc3a09..1fdc1481e 100644
--- a/package/refpolicy/Config.in
+++ b/package/refpolicy/Config.in
@@ -1,7 +1,7 @@
 config BR2_PACKAGE_REFPOLICY
 	bool "refpolicy"
 	depends on BR2_TOOLCHAIN_HAS_THREADS # policycoreutils
-	depends on BR2_TOOLCHAIN_USES_GLIBC # policycoreutils
+	depends on !BR2_TOOLCHAIN_USES_MUSL # policycoreutils
 	depends on BR2_PACKAGE_AUDIT_ARCH_SUPPORTS # policycoreutils
 	depends on !BR2_STATIC_LIBS # policycoreutils
 	depends on !BR2_arc # policycoreutils
@@ -28,11 +28,11 @@ config BR2_PACKAGE_REFPOLICY
 
 	  https://github.com/TresysTechnology/refpolicy
 
-comment "refpolicy needs a glibc toolchain w/ threads, dynamic library"
+comment "refpolicy needs a uClibc or glibc toolchain w/ threads, dynamic library"
 	depends on !BR2_arc
 	depends on BR2_PACKAGE_AUDIT_ARCH_SUPPORTS
 	depends on BR2_STATIC_LIBS || !BR2_TOOLCHAIN_HAS_THREADS || \
-		!BR2_TOOLCHAIN_USES_GLIBC
+		BR2_TOOLCHAIN_USES_MUSL
 
 if BR2_PACKAGE_REFPOLICY
 
diff --git a/package/setools/Config.in b/package/setools/Config.in
index d7b119ffc..364c6dbf6 100644
--- a/package/setools/Config.in
+++ b/package/setools/Config.in
@@ -4,7 +4,7 @@ config BR2_PACKAGE_SETOOLS
 	depends on !BR2_STATIC_LIBS
 	depends on BR2_INSTALL_LIBSTDCPP
 	depends on BR2_USE_WCHAR
-	depends on BR2_TOOLCHAIN_USES_GLIBC # libselinux
+	depends on !BR2_TOOLCHAIN_USES_MUSL # libselinux
 	# bfin: infamous _ symbol prefix issue
 	# nios2: triggers some toolchain issue "No symbol version
 	# section for versioned symbol"
@@ -29,8 +29,8 @@ config BR2_PACKAGE_SETOOLS
 
 	  https://github.com/TresysTechnology/setools3/wiki
 
-comment "setools needs a glibc toolchain w/ threads, C++, wchar, dynamic library"
+comment "setools needs a uClibc or glibc toolchain w/ threads, C++, wchar, dynamic library"
 	depends on !BR2_TOOLCHAIN_HAS_THREADS || BR2_STATIC_LIBS \
 		|| !BR2_USE_WCHAR || !BR2_INSTALL_LIBSTDCPP \
-		|| !BR2_TOOLCHAIN_USES_GLIBC
+		|| BR2_TOOLCHAIN_USES_MUSL
 	depends on !BR2_nios2 && !BR2_bfin && !BR2_arc
-- 
2.13.0

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

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[Adam Duskett]

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

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

[Thomas Petazzoni]

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 Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[Peter Korsgaard]

>>>>> "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?

-- 
Bye, Peter Korsgaard

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

[Adam Duskett]

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

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

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[Adam Duskett]

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

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

[Peter Korsgaard]

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

-- 
Bye, Peter Korsgaard

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

[Waldemar Brodkorb]

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

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

[Adam Duskett]

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

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

[Yann E. MORIN]

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.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

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

[Arnout Vandecappelle]

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


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

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

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[Waldemar Brodkorb]

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

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

[Alexey Brodkin]

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

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

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[Waldemar Brodkorb]

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

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

[ratbert90]

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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20171012/ed3677fd/attachment.html>

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

[Alexey Brodkin]

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