Le 24/07/2016 23:29, Rick Moen a écrit :
> Quoting Didier Kryn (kryn@???):
>
>> 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.
>
Would it make any sense to have systemd with no application talking
to it? Doesn't it imply it couldn't start any service. Therefore no DE,
no ssh, no ntp, maybe even no login...
Didier
::
Re: [DNG] Why Debian 8 Pinning is (…
