On (10/05/16 06:40), Stephen Gallagher wrote:
I was thinking this morning again about how we could deal with the
32-bit on 64-bit problem. On Fedora 24 and newer, we have the ability to use rich RPM
dependencies (Recommends: sssd-client.i686 if glibc.i686) That doesn't help on older
Fedora or RHEL systems though.
Fedora 23 has rpm-4.13.0-0.rc1.13.fc23
and it should work well with weak dependencies.
Fedora 22 will be EOL in 2 months.
(one month after fedora 24 final release[2])
So we needn't care much about fedora 22. :-)
What if we were to split the nss_sss.so.2 library into its own
subpackage and then turn off the automatic dependency generation for it? We could then
have sssd-common Requires: the one for the same arch and Recommends: the one for the other
architecture (or Requires: for older systems that don't support Recommends:)
Debian has already nss modeule in separate package libnss-sss
https://packages.debian.org/jessie/libnss-sss
I'm fine with separate packsge.
Do we want to have Recommends or weaker dependency only Suggest?
But there is a question.
Should sssd-common recommend "libnss-sss" or recommend shoudl be added to
glibc.
glibc-common.i686
Recommends: libnss-sss%{?_isa}
or it is purpose of reverse weak dependencies (Supplements, Enhances)???
libnss-sss.686
Supplements: glibc-common%{?_isa}
The result would be that default installations of the OS could have
both versions of nss_sss.so.2 but of course the 32-bit one wouldn't actually do
anything unless someone installs glibc.i686 (or it is pulled in by something else).
This would not be an approach I would recommend in general, but the NSS client is a
special case: it's only meaningful if glibc is installed because otherwise nothing
would ever call into it. Even for the primary arch, it's a safe assumption that glibc
will always be installed at least for that arch, so there's no reason to add that
dependency explicitly.
LS
[1]
https://bodhi.fedoraproject.org/updates/?packages=rpm
[2]
http://fedoraproject.org/wiki/Releases/24/Schedule