Idea for multilib handling in Fedora and RHEL

[Stephen Gallagher]

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.

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:) 

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.

[Lukas Slebodnik]

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

[Jakub Hrozek]

On Tue, May 10, 2016 at 01:24:51PM +0200, 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. :-)
>  
>  >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. 
Me too. In addition, this might be nice for other projects (winbind?)
who would like to use the same client modules..

[Stephen Gallagher]

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.


> > 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?
>   
Suggests is functionally meaningless for this purpose. Our tools (dnf,
PackageKit) do not readily have a mechanism for directly installing Suggests. In
practice, Suggests: is only useful for disambiguation.

For example:
Requires: virtual(database)
Suggests: mariadb

(Which means that if no package on the system already provides
"virtual(database)", then mariadb will be installed to satisfy it.

"Recommends" is basically the same as "Requires" except that you can
uninstall
it later without affecting the package that pulled it in. (Or you can tell DNF
to install only required packages)


>  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}
>   

I'm pretty sure we can't do that because it would effectively be a circular
dependency. To remove that cycle, we'd still have to remove the autorequires on
glibc, which would eliminate the advantage to having glibc pull it in on its
own. I think it's better to keep the dependencies tied to SSSD itself.


>  or it is purpose of reverse weak dependencies (Supplements,
> Enhances)??? 
>  libnss-sss.686 Supplements: glibc-common%{?_isa}
>   

Reverse deps aren't available on RHEL 6 or RHEL 7.


> > 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 
>  _______________________________________________ sssd-devel mailing list 
>  sssd-devel(a)lists.fedorahosted.org 
>  https://lists.fedorahosted.org/admin/lists/[e-mail]
>

[Lukas Slebodnik]

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}


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?

LS

[Stephen Gallagher]

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/[e-mail]...

[Lukas Slebodnik]

On (10/05/16 09:29), Stephen Gallagher wrote:
> 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}
>  
I would like to avoid using strict dependencies on fedora.
I have a plan to more use weak dependencies for fedora

replace strict requirements in sssd-common on libsss_sudo and libsss_autofs
...

> 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.
>  
We already have a small deviation between upstream and downstream spec file.
Upstream spec file does not have alternatives for sssd-libwbclient.
But we still try to be very close.

Please file upstream + downstream tickets(rhel7 and/or rhel6)
I think you already have some ideas.
We are looking forward to review a patch :-)

LS
>
>
>[1]
>https://lists.fedoraproject.org/archives/list/[e-mail]/thread/Q5LMMPVEORM76IOPGKYS4XJ6VZ2WLAAX/