[SSSD] [PATCH] Split the providers into separate subpackages

Stephen Gallagher sgallagh at redhat.com
Mon Jun 10 12:56:37 UTC 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/10/2013 07:17 AM, Lukas Slebodnik wrote:
> On (10/06/13 10:03), Jakub Hrozek wrote:
>> On Fri, Jun 07, 2013 at 06:24:48PM +0200, Lukas Slebodnik wrote:
>>> 1. I like idea of divided subpackages. If someone wants only
>>> ldap backend, he needn't install samba-libs (and its
>>> dependencies)
>>> 
>>> 2. There isn't any rpmlint warnings.
>>> 
>>> I tested yum upgrade upgrade with installed sssd and
>>> freeipa-client. New packages were installed for dependencies: 
>>> sssd-ad sssd-common sssd-ipa sssd-krb5 sssd-krb5-common
>>> sssd-ldap Everything worked as expected.
>>> 
>>> Then I decided to remove sssd-ad: yum remove sssd-ad and
>>> packeges "freeipa-client, sssd" were also removed. I was little
>>> bit confused, because I didn't want to remove sssd and sssd
>>> replied to getent command after packages "freeipa-client, sssd"
>>> were removed.
>> 
>> That's because freeipa-client currently requires sssd, we might
>> want open a ticket to make them require just sssd-ipa.
>> 
> 
> The most confusing thing was for me that sssd was removed. Yes, we
> should file a ticket to freeipa-client after releasing sssd.
> 
>>> 
>>> I think, that other users may be also confused with this
>>> situation. Then I looked to the patch and I found out, that: 
>>> --sssd is only "meta package",which require all backedns
>>> subpackages --sssd doesn't contain any useful files 
>>> --everything important is in package sssd-common.
>>> 
>>> 
>>> Maybe we should update package description of sssd and
>>> sssd-common. I hope that system administrators relies on output
>>> of "yum info" and there isn't it very well explained.
>>> 
>> 
>> Thanks, I updated the summary of both sssd and sssd-common.
>> Hopefully it would be clearer now.
>> 
> 
> Thank you.
> 
>>> Summary: Everything works well, but I was little bit confused.
>>> 
>>> Any other opinions?
>>> 
>>> One nitpick inline
>>> 
>>> 
> 
> I think, that patches are OK. Does anybody have another comments or
> objections?
> 

Nack.

When adding "Provides:" and "Obsoletes:", it is inappropriate to do
Obsoletes: libsss_sudo < %{version}-%{release}

The Fedora guidelines require that the Obsoletes: be a specific
version (the last one before the change occurred). So

Obsoletes: libsss_sudo <= 1.9.5

The reason for this is so we don't force yum to handle Obsoletes
processing at every update (which I'm told is expensive).

We only need to carry this explicit Obsoletes: until Fedora no longer
has install media with the older version (so until F19 is the oldest
supported version).


Why do you have Conflicts: sssd < %{version}-%{release}? Given that
the packages are identically-named (and that name isn't 'kernel'),
this should be unnecessary.


Is there a particular reason that the proxy provider doesn't have a
subpackage as well?

If we're breaking up packages to make it easier to create a minimal
install, might it be best to just drop all of the manpages into an
sssd-docs subpackage (that gets pulled in by the sssd metapackage)?
Including translations, those can add up. Which brings me to my next
point:

The provider subpackages have only the English manpage included in
them. The translated ones are all landing in the sssd-common package.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlG1zQUACgkQeiVVYja6o6O8RQCfactr8jeLDXzn05Qaxt139U1s
X+8AoK61xE6bvqWroEoAyVokKoTQ2arC
=ky+T
-----END PGP SIGNATURE-----



More information about the sssd-devel mailing list