On 05/10/2016 09:00 AM, Lukas Slebodnik wrote:
On (10/05/16 08:42), Stephen Gallagher wrote:
> On 05/10/2016 07:24 AM, Lukas Slebodnik wrote:
>> 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. :-)
>>
>
> I don't particularly care about Fedora 22. I *do* care about RHEL/CentOS 6 and
7.
OK
I think we all agree on separate package for libnss_sss.so.2 :-)
So let's split discussion into two parts
A) fedora + weak dependencies
Would that work for you?
libnss-sss
Supplements: glibc-common%{?_isa}
What I'd really like to do is have sssd-common have the following:
Name: sssd-common
Requires: sssd-clients-nss%{_isa}
Requires: sssd-clients-nss%{multilibarch} if glibc%{multilibarch}
This approach would make it a hard dependency to have the appropariate client
software if glibc was installed.
Unfortunately, that's impossible right now due to limitations in the compose
tools of Fedora (see this[1] thread for an explanation). Also we'd need to
create %{multilibarch} or get redhat-rpm-config to add it as an available option.
So for now, I think we'd actually need to do:
Name: sssd-clients-nss
Supplements: (glibc-common%{?_isa} if sssd-common)
Otherwise, we would be installing the NSS module unconditionally for all glibc
installations, which is probably not quite what we want.
B) rhel
IIRC your initial mail you proposed to
add requirement to sssd-common on require 32 and 64 bit "libnss-sss"
+ remove automatically generated dependencies for libnss-sss.i686
otherwise the installation of sssd-common.x86_64 would install
32bit glibc
If yes please file downstream bugs for rhel6 and rhel7.
I am not sure whether we want to complicate upstream spec file for rhel.
(It's already complicated enough due to rhel/fedora compatibility)
Or do you prefer to have such change also in upstream spec file?
Maybe it's time to split the usptream spec file into a Fedora-specific one and a
RHEL-specific one. There's still plenty of value in being able to produce a
RHEL-installable set of packages straight from the upstream sources, but you may
be right that keeping all the logic in a single spec file is getting unwieldy.
I'll leave that to you and Jakub to decide, though.
[1]
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedora...