[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