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

Stephen Gallagher sgallagh at redhat.com
Tue Jun 11 13:37:49 UTC 2013


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

On 06/11/2013 06:03 AM, Jakub Hrozek wrote:
> On Mon, Jun 10, 2013 at 03:49:34PM -0400, Stephen Gallagher wrote: 
> On 06/10/2013 02:24 PM, Jakub Hrozek wrote:
>>>> On Mon, Jun 10, 2013 at 08:56:37AM -0400, Stephen Gallagher
>>>> wrote:
>>>>> -----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
>>>>> 
>>>> 
>>>> OK, in my defense I've seen these in some of the specfiles
>>>> I've got cloned from Fedora's dist-git (not that it would
>>>> make them correct).
>>>> 
>>>> I made the changes in the version that is attached, just with
>>>> a differens version to compare against. I think your
>>>> suggestion would make sense for a Fedora package, but in
>>>> upstream, we want to obsolete all the nightly builds prior to
>>>> the switch as well.
>>>> 
>>>> So I added another point version number (minor versions come
>>>> cheap) and compared against 1.9.93.
>>>> 
> 
> It needs to be <= 1.9.93. Just less-than won't upgrade packages
> *at* 1.9.93
> 
> Wouldn't things be easier to remember if you just bumped version.m4
> to 1.9.94 instead? Then you don't need to remember to revert the
> specfile patch. (You can just release 1.9.94. No one is really
> going to notice if the upstream minor release number jumped two
> digits instead of one between pre-releases).
> 
> 
>> Yes, if it's OK to bump the version then it's definitely easier.
>> Done.
> 
> 
>>>>> The reason for this is so we don't force yum to handle
>>>>> Obsoletes processing at every update (which I'm told is
>>>>> expensive).
>>>>> 
>>>> 
>>>> I see, I didn't know that.
>>>> 
> 
> Technically, it also allows the capability to add that back in as
> a package or subpackage at a higher version at some later date
> without breakage (because the re-added one would be at a higher
> N-V-R). That's not something that matters to us though, just a bit
> of academia.
> 
>>>>> 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.
>>>>> 
>>>> 
>>>> I wanted to be really defensive and make sure that everything
>>>> the old version contained is gone with the new version. That
>>>> Conflicts: is gone with the attached patches.
>>>> 
>>>>> 
>>>>> Is there a particular reason that the proxy provider
>>>>> doesn't have a subpackage as well?
>>>>> 
>>>> 
>>>> Just that the proxy provider has no dependencies. But from a 
>>>> logical standpoint it makes sense, so there is a proxy
>>>> subpackage now, too.
>>>> 
> 
> Thanks, but you forgot to add it to the dependencies of the 'sssd' 
> meta-package.
> 
> 
>> Oops, fixed.
> 
> 
> If we're being pedantic about this, we should probably split out
> the 'simple' provider as well, but I'm not going to nack over it.
> It's < 40k.
> 
> 
>> I think it's better if the simple provider stays in the common
>> package. It can be used along with any other provider, so the
>> other providers would have to require it anyway. Also, it has no
>> dependencies.
> 
> 
>>>>> 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.
>>>> 
>>>> I don't really like this option. As a user of SSSD I would
>>>> expect the sssd-ad man page to be present if I installed the
>>>> sssd-ad package. Also, I think it is better to have a single
>>>> man page installed (even if it's along with the translations)
>>>> for the provider I care about than the whole bunch. The space
>>>> savings provided by this split would also come by the means
>>>> of not installing all the dependencies rather than not
>>>> installing the files that form the providers.
>>>> 
>>>> Thank you for the review, new patches are attached.
>>>> 
> 
> 
> Hmm, the translated manpages seem to have disappeared from the
> builds entirely:
> 
> 
>> I see the same behaviour with parallel build (also with master
>> w/o these patches), but with an in-tree build, the man pages are
>> generated fine.
> 
>> Here is a scratch build I built: 
>> http://koji.fedoraproject.org/koji/taskinfo?taskID=5490069
> 
>> For instance, check out the sssd-ldap subpackage: $ rpm -qpl
>> sssd-ldap-1.9.94-0.fc19.x86_64.rpm | grep man 
>> /usr/share/man/ja/man5/sssd-ldap.5.gz 
>> /usr/share/man/man5/sssd-ldap.5.gz 
>> /usr/share/man/uk/man5/sssd-ldap.5.gz
> 
> 
> [sgallagh at sgallagh520:x86_64 (master *)]$ rpm -qpl 
> /home/sgallagh/workspace/sssd/x86_64/rpmbuild/RPMS/x86_64/sssd-*.rpm
>
> 
|grep man
> /usr/share/man/man5/sssd-ad.5.gz /usr/share/man/man8/pam_sss.8.gz 
> /usr/share/man/man8/sssd_krb5_locator_plugin.8.gz 
> /usr/share/man/man1/sss_ssh_authorizedkeys.1.gz 
> /usr/share/man/man1/sss_ssh_knownhostsproxy.1.gz 
> /usr/share/man/man5/sssd-simple.5.gz 
> /usr/share/man/man5/sssd-sudo.5.gz 
> /usr/share/man/man5/sssd.conf.5.gz 
> /usr/share/man/man8/sss_cache.8.gz /usr/share/man/man8/sssd.8.gz 
> /usr/share/man/man5/sssd-ipa.5.gz 
> /usr/share/man/man5/sssd-krb5.5.gz 
> /usr/share/man/man5/sssd-ldap.5.gz 
> /usr/share/man/man8/sss_debuglevel.8.gz 
> /usr/share/man/man8/sss_groupadd.8.gz 
> /usr/share/man/man8/sss_groupdel.8.gz 
> /usr/share/man/man8/sss_groupmod.8.gz 
> /usr/share/man/man8/sss_groupshow.8.gz 
> /usr/share/man/man8/sss_obfuscate.8.gz 
> /usr/share/man/man8/sss_seed.8.gz 
> /usr/share/man/man8/sss_useradd.8.gz 
> /usr/share/man/man8/sss_userdel.8.gz 
> /usr/share/man/man8/sss_usermod.8.gz
> 
> 
> I'm running it as a Koji scratch-build right now to make sure it's
> not some peculiarity of my system, but I think there's something
> wrong with the *.lang files :-/


My scratch-build against F20 also did not include translated manpages:
http://koji.fedoraproject.org/koji/taskinfo?taskID=5488765

Something broke somewhere, I assume. Let's track this down before we
push these patches, please.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlG3KC0ACgkQeiVVYja6o6M7dQCgiIiF2XjWApPpPPBgfht9KWmM
rfEAnA4e/Iim9vhLA8p/co0tlNBBSAMP
=V1l3
-----END PGP SIGNATURE-----



More information about the sssd-devel mailing list