On 16 March 2017 at 12:20, Jonathan Wakely <jwakely@fedoraproject.org> wrote:
[..]
I can only repeat that such people should consider linking own binaries
against uClibc as this implementation is not affected by issue with hidden
loading NSS DSOs which probably make such binaries useless on moving around
against latest fedora/RH7 and RH5.

If you don't move the binaries around you don't have a problem.

You're still assuming you know everybody's use cases.

As an argument against what I'm suggesting already in this thread was used case statically linked binaries in chrooted envs with some old legacy binaries.
Risk coming from such scenarios is not as a "potentially may happen in future" but something which is already happening probably +1 time a day globally.

If statically linked with glibc binaries will be linked on top latest Fedora and will be used inside suh envs  crash by NSS issue is almost unavoidable because such binary it will be trying to load NSS DSO modules from old glibc.
Again: such problems will never happen if using in such extreme/unusual conditions static libc will be allowed but only against uClibc which is not affected by NSS ABI issues.

And last argument/nail to this NSS issue coffin.
This issue is so well known to glibc developers that they made glibc static code producing static NSS modules as statically linked modules. Such support is provided only for two types of NSS methods: files and dns. This is kind of very minimal NSS support which potentially in all cases of using statically linked binaries will be possible to use.
Problem is that Fedora glibc is not ready to embed such code statically because current build procedure does not builds static NSS binaries for files and dns methods. So none of the Fedora packages provides libnns_{files,dns}.a !!!
Other consequence of above: if someone will be even tying to build statically linked binaries using other methods of mapping like sss or other it will be not possible to build such binaries because static glibc code is not prepared to be linked with more than those handful/stub files and dns NSS methods support.

BTW: during checking that current Fedora glibc static binaries are not ready even solve those well known scenarios I found that already glibc spec file is generating glibs-nss-devel subpackage.
S rpm -qpl glibc-nss-devel-2.25.90-1.fc27.x86_64.rpm
/usr/lib64/libnss_compat.so
/usr/lib64/libnss_db.so
/usr/lib64/libnss_dns.so
/usr/lib64/libnss_files.so
/usr/lib64/libnss_hesiod.so
/usr/lib64/libnss_nis.so
/usr/lib64/libnss_nisplus.so
Looks like someone didn't know that those symlinks are not a devel symlinks and they are installed by am/ac/lt glibc build suit only because it was easier to use library build/install method.
Will try to create bugzilla ticket to delete those symlinks in %install, remove glibc-nss-devel and add it to Obsoletes list.

Another subject related to the NSS libc issue is provide fully working solutions to any future solutions when NSS ABI issue will be hit again ale on glibc upgrade will be on the system on some with "in the middle state" when glibc will be due upgrade and part of the upgrade procedure will be necessary to execute some script finishing such upgrade. There are two possible solutions:
1) classic like it is already implemented in Solaris where is provided /sbin/sh which is static binary not affected by NSS ABI issues
2) use rpm embedded lua interpreter to execute bits of such procedures.

BTW point 2). To avoid /bin/sh dependencies IMO it would be good to invest some time to review existing %post{,un}, %pre{,un} %trigger scripts to rewrite as much as possible to use lua rpm internal interpreter instead SH.
However I think that provide in Fedora something like /bin/sash (which is still available on http://members.tip.net.au/~dbell/programs/) may be very attractive for some docker/minimalistic scenarios. So provide in Fedora sahs may be kind of OOTB and fully supported better solution than probably currently used :)
Definitely this minimalistic shell (his static binary on x84_64 has only ~950KB) is very useful in some systems rescue scenarios. It saved my ass many times in the past. It is perfect as well as main shell interpreter inside initrd.


So .. one more time: my proposition is not about cutting off all people from using statically libc linked binaries.
One more time: it is misunderstanding and this is not what I'm proposing.
Part of my proposition with stop provide glibc-static is to propose alternative and 100% working solutions but without glibc-static packages.

You can take it as provide Right(tm) Solutions of NSS ABI glibc issues to all average joe-developers which are 99.99%  not aware that potentially they are shooting in own foot (really number of people around the world aware of those issues is very low/handful).
In all those rare cases instead glibc-static should be used uClibc (or alternative).

uClibc is actively developed and widely used on many CPU platforms as it is essential on many embedded platforms so risk that are some issues with this library is already probably the same as with using glibc.

uClibc is already part of the Fedora distribution and it is functional replacement of glibc-static in scenarios like using embedded/minimalistic system images, rescue  and early system boo system and other similar scenarios.

So nothing more needs to be done now except provide in Fedora documentation that because glibc-static has (by its natural internal complexity) some well known ABI issues Fredora to prevents happen those issues stops distributing glibc-static and provides as replacement using uClibc static libc binaries.

One more time: provide package and allow to end developers use glibc-static is nothing more than asking for troubles.

All test suits using full static linking testing be can abandon as static linking with libc is a bit pointless (as there is nothing special in glibc static binaries which may expose some linker issues during such tests).
And/or such test suits should be tweaked to use uClibc as well as only officially supported method of using 100% statically linked binaries so testing such solution on distribution build layer will be provided as well. In such scenarios uClibc will be additionally tested on Distro layer during regular builds of some distribution packages.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH