Quoting Didier Kryn (k...@in2p3.fr): > Don't remember which package depends on some libkerberos5. > Assuming it's openssh or some component of pam.
Package openssh-client. $ ldd $(which ssh) linux-gate.so.1 => (0xb76ec000) libresolv.so.2 => /lib/i686/cmov/libresolv.so.2 (0xb7672000) libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb751a000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7516000) libz.so.1 => /usr/lib/libz.so.1 (0xb7502000) libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xb74d3000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb738c000) /lib/ld-linux.so.2 (0xb76ed000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb72da000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb72b7000) libcom_err.so.2 => /lib/libcom_err.so.2 (0xb72b4000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb72ad000) libkeyutils.so.1 => /lib/libkeyutils.so.1 (0xb72a9000) libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7290000) $ On a system that actually uses Kerberos, pam_krb5.so also gets involved, and I don't remember how that actually works. (I've done some Kerberos in setting up Hadoop on CentOS 6, but not much more than just getting it going.) > This raises a fundamental problem of distros. openssh and pam must be > able to make use of as many authentication protocols as possible to > cover the needs of all users. How can you reach this goal without > linking them to the corresponding libraries? It is indeed a thorny problem. One common answer is the Gentoo-style one where you employ USE flags or equivalent, and recompile & rebuild packages to trim build dependencies. It's certainly possible to carry out a similar action on a deb-packaged distro by locally rebuilding deb packages, tweaking the 'rules' file before compiling to reduce build dependencies. Or, as you say, there could be regular packages with several different flavours, some with more dependencies, some with fewer. > The case of libsystemd0 is different. In an OS proposing > systemd, it is normal to have libsystemd0, but not in a system which > excludes it completely. Here is the choice Devuan faces: if systemd > is installable, then many packages must depend on libsystemd, if no > package depends on it, then systemd is not installable. I followed you all the way to the last sentence, which I'm pretty certain is simply not correct. E.g., on my dest Debian 8 'Jessie' VM system (if I were to remove the current embargoing of system from /etc/apt/preferences), I could remove all packages that depend on libsystemd0, but then systemd would most certainly be nonetheless installable. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng