| |||||||||||||
The case for the /usr mergeThe case for the /usr mergePosted Jan 27, 2012 0:56 UTC (Fri) by JoeBuck (subscriber, #2330)In reply to: The case for the /usr merge by rickmoen Parent article: The case for the /usr merge I've had a number of issues over the decades related to what is in /bin vs /usr/bin, or what is in /sbin vs /usr/sbin. I will be happy to see the distinction go away (and Solaris has already done this). Your "don't do that then" assumes that people can maintain a careful, rigorous, and correct distinction between /{bin,lib,sbin} and /usr/{bin,lib,sbin} and keep it clean, and evidence shows that they cannot.
(Log in to post comments)
The case for the /usr merge Posted Jan 27, 2012 1:15 UTC (Fri) by rickmoen (subscriber, #6943) [Link] Joe wrote:Your "don't do that then" assumes that people can maintain a careful, rigorous, and correct distinction between /{bin,lib,sbin} and /usr/{bin,lib,sbin} and keep it clean, and evidence shows that they cannot. Your assertion rests on an incorrect foundational premise. I believe I said 'inappropriate library dependencies'. (Emphasis added.) That's not particularly difficult, as few contents in /lib are critical in situations where /usr is unavailable. One is the mount utility. Checking locally:
$ ldd /bin/mount
linux-gate.so.1 => (0xb7867000)
libblkid.so.1 => /lib/libblkid.so.1 (0xb7842000)
libuuid.so.1 => /lib/libuuid.so.1 (0xb783e000)
libselinux.so.1 => /lib/libselinux.so.1 (0xb7823000)
libsepol.so.1 => /lib/libsepol.so.1 (0xb77ee000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb76a7000)
/lib/ld-linux.so.2 (0xb7868000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb76a2000)
$
Gee, doesn't seem like I even had to do anything to avoid inappropriate /usr dependencies for that one. Watch out for straw-man arguments, Joe. They can make you sneeze. Rick Moen
The case for the /usr merge Posted Jan 27, 2012 1:17 UTC (Fri) by rickmoen (subscriber, #6943) [Link]
And I meant /bin, not /lib. Maybe sjj can breathlessly catch my error again, though this time he has only about a 30-second window.
The case for the /usr merge Posted Jan 27, 2012 7:24 UTC (Fri) by hillman (guest, #82597) [Link]
WHAM!! You nailed him again! Way to go, bro.
The case for the /usr merge Posted Jan 27, 2012 1:26 UTC (Fri) by josh (subscriber, #17465) [Link] From just the binaries installed on my system: /bin/ntfsdecrypt: libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26 (0x00007f72ccfd8000) libtasn1.so.3 => /usr/lib/x86_64-linux-gnu/libtasn1.so.3 (0x00007f72cc7c5000) libz.so.1 => /usr/lib/libz.so.1 (0x00007f72cc5ad000) libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f72cc17f000) /bin/ping6: libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007fce2b78c000) libz.so.1 => /usr/lib/libz.so.1 (0x00007fce2afec000) /sbin/fsck.cramfs: libz.so.1 => /usr/lib/libz.so.1 (0x00007f7093762000) /sbin/mkfs.cramfs: libz.so.1 => /usr/lib/libz.so.1 (0x00007f28d6b53000) /sbin/nfnl_osf: libnfnetlink.so.0 => /usr/lib/libnfnetlink.so.0 (0x00007fa4f20a8000) /sbin/umount.udisks: libdbus-glib-1.so.2 => /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x00007f7af2ca1000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007f7af2832000) libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0x00007f7af1c4a000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00007f7af1a47000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x00007f7af1842000) libz.so.1 => /usr/lib/libz.so.1 (0x00007f7af0fd0000) /sbin/wpa_supplicant: libpcsclite.so.1 => /usr/lib/libpcsclite.so.1 (0x00007f108a009000) libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f1089db7000) libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f10899f1000) libz.so.1 => /usr/lib/libz.so.1 (0x00007f1088964000) So, making /bin and /sbin self-contained without requiring /usr would require expanding the "minimal" root filesystem to include zlib, libcrypto, PKCS#11, PC/SC smart-card support, gnutls, libtasn, libnfnetlink, several glib libraries, gio, dbus, and OpenSSL. All because, for example, someone *might* need to run wpa_supplicant to connect to a wireless network to mount /usr over NFS. And this from Debian, a distribution which goes out of its way to allow its users to continue using insane use cases rather than just saying "don't do that then". (One of Debian's biggest features and biggest faults.)
The case for the /usr merge Posted Jan 27, 2012 5:44 UTC (Fri) by BenHutchings (subscriber, #37955) [Link]
Hell, even nfs-common relied on libraries in /usr for several months and I don't think we got any bug reports from users before fixing it.
The case for the /usr merge Posted Jan 27, 2012 8:50 UTC (Fri) by kju (subscriber, #61936) [Link]
Well in this context I believe the biggest failing of Debian (and still a feature) is to include many features of a package even if most users won't need it. Seriously when I see from your post that for example wpa_supplicant depends on libpcsclite it makes me shudder. Yes it's nice to have smartcard support in wpa_supplicant but the vast majority of users won't need it and this just adds an unncessary dependency.
The case for the /usr merge Posted Jan 27, 2012 11:49 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
I need it. Why should it be removed in the name of separate /bin directory?
The case for the /usr merge Posted Jan 27, 2012 12:01 UTC (Fri) by kju (subscriber, #61936) [Link] And because you need it, everyone else should have binaries which have unnecessary depends and therefore use up more resources? It would make more sense to have a wpasupplicant-full package or something which includes all the bells and whistle and a more stripped down version for the majority of us.
The case for the /usr merge Posted Jan 27, 2012 12:45 UTC (Fri) by RobSeace (subscriber, #4435) [Link]
Or, why couldn't it just dlopen() rarely needed libs like this on the fly, if and only if it actually needs them at the time? Then, it wouldn't be linked against them and actually require them to run at all...
The case for the /usr merge Posted Jan 27, 2012 14:20 UTC (Fri) by mpr22 (subscriber, #60784) [Link] The sanity or otherwise of that approach is so wildly variable that it can only be evaluated on a case-by-case basis. dlopen() adds a significant comprehensibility overhead compared to just invoking the library's API directly, and may well preclude sane-and-convenient use of the normal programming model for the library in question. (The latter effect becomes particularly severe when you're writing a C++ program using C++ libraries, of course.)
The case for the /usr merge Posted Jan 27, 2012 14:51 UTC (Fri) by RobSeace (subscriber, #4435) [Link]
True enough... But, if it's just some obscure rarely used feature, I'd think it makes sense anyway... Even if you don't want to indirect all API calls through dlsym() and such, what you could do is separate out all the code that interacts with that library into a sort of plug-in library of its own, needing just one simple call into that lib from the main app to do everything... The separate lib can still directly call all functions from the system library with no confusing indirection, and even be linked against it if you want... (Or, the main app can just dlopen(RTLD_GLOBAL) it prior to dlopen()'ing this separate lib...)
The case for the /usr merge Posted Jan 27, 2012 16:45 UTC (Fri) by dashesy (subscriber, #74652) [Link]
While the whole plugin approach is nice, it is not worth it just to save a few bytes. It might even produce bigger binaries, and the additional complexity will bring more errors.
The case for the /usr merge Posted Jan 27, 2012 17:00 UTC (Fri) by RobSeace (subscriber, #4435) [Link]
I didn't think the idea was to reduce app size, but rather to reduce dependencies required for rarely-used features... So that one could choose NOT to install the plugin and its required system library, and still be able to use all the more common features of the app, and merely lose the ability to use the obscure feature...
Just run gentoo :-) n/t Posted Jan 28, 2012 12:22 UTC (Sat) by Wol (guest, #4433) [Link]
Cheers,
Wol
The case for the /usr merge Posted Jan 29, 2012 21:55 UTC (Sun) by elanthis (guest, #6227) [Link]
This is in part because the library wasn't designed for this use case in the first place.*
However, why should the library be directly dlopen'd? Why not put a plugin architecture into wpa_supplicant itself, with the plugin linking against the library normally, and with only a very narrow and plugin-friendly interface being shared across that dlopen boundary? This even makes it trivial to have the package manager intelligently support the package dependencies by putting the plugin in its own package; users who need the feature install the plugin and get all dependencies pulled in, and users who don't will not need those. There's then a case to be made that the network configuration tools in Anaconda and the desktop tools need to be made aware of feature package dependencies to pull these things in automatically, but that's a polish thing (not FOSS's strength, but not out of the realm of possibility by any stretch).
[*] There's an argument to be made -- especially in the FOSS world where the source is available and modifiable by anyone and everyone -- that libraries should offer the kinds of interfaces their clients prefer, rather than client applications making "not our fault" claims when library interfaces don't allow features users want (like moving dependencies from compile-time to run-time).
The case for the /usr merge Posted Jan 30, 2012 2:30 UTC (Mon) by HelloWorld (guest, #56129) [Link]
The question is, why bother? It works just fine now and nobody outside the embedded world cares about the few dozen kB of "bloat" libpcsclite induces. On embedded systems, a custom-compiled version can be used. Any amount of time spent on stuff like this would a useless waste of developer resources.
The case for the /usr merge Posted Jan 27, 2012 14:30 UTC (Fri) by foom (subscriber, #14868) [Link]
I'd bet that nobody has actually ever noticed the extra resources it uses, other than the very scarce "resource" of the extra lines in the ldd output.
The case for the /usr merge Posted Jan 27, 2012 11:48 UTC (Fri) by sorpigal (subscriber, #36106) [Link]
> So, making /bin and /sbin self-contained without requiring /usr would require expanding the "minimal" root filesystem to include zlib, libcrypto, PKCS#11, PC/SC smart-card support, gnutls, libtasn, libnfnetlink, several glib libraries, gio, dbus, and OpenSSL.
You say this like it's ridiculous, but I don't see a big problem. On one of my systems, also Debian, I have 10 binaries in /bin or /sbin which need /usr, on another I have 11. They depend, between them, on 22 unique libraries. This seems like a small problem to require such a big solution.
"10 of 332 binaries in /bin and /sbin require /usr. Obviously the correct solution is to get rid of /usr and merge it into /, and not to move 22 libraries into /lib/" - does that sound right?
The case for the /usr merge Posted Jan 27, 2012 14:21 UTC (Fri) by mpr22 (subscriber, #60784) [Link] And one day you find that /usr/lib contains nothing but high-level GUI libraries, because creeping dependencies have slurped everything simpler into /lib. Given that a lot of "separate /usr" advocates also seem to be "slimline /" advocates...
|
|||||||||||||