[Bug 487296] Review Request: sssd - System Security Services Daemon

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=487296





--- Comment #7 from Martin Nagy <mnagy at redhat.com>  2009-03-04 14:40:04 EDT ---
(In reply to comment #5)
> (In reply to comment #4)
> No documentation is expected, there really is not one (yet?). See below for the
> .so issue.

Good enough.

> > %files section:
> > %{_sharedstatedir}/sss/ expands to /usr/com/sss/ which doesn't exist. I think
> > you meant %{_localstatedir}/%{_lib}/sss/
> > 
> 
> On my F10 system:
> $ rpm --showrc | grep /var/lib
> -14: _sharedstatedir /var/lib
> 
> RPM documentation really says that sharedstatedir expands to /usr/com/sss but
> it's not true. FWIW, the macro is defined in /usr/lib/rpm/platform/*. There is
> also a corresponding autotools macro.

On my F9 system it expands to /usr/com. If this package is only going to be
packaged for F10 and higher this is ok. I'll try to confirm that this is the
right way, just to make sure.

> > Additionally, I think the %{sssd_release} and %{sssd_version} macros aren't
> > really useful. Please consider using standard macros.
> > 
> 
> Umm, okay. I pretty much continued using them since they were in the specfile I
> based this upon and also in all the related samba packages.

I can see you're reluctant :) It's not really a requirement, but it would
really make me happy. FYI, you can also use rpmdev-newspec for template
generation in the future if you want.

> > MUST: The sources used to build the package must match the upstream source, as
> > provided in the spec URL. Reviewers should use md5sum for this task. If no
> > upstream URL can be specified for this package, please see the Source URL
> > Guidelines for how to deal with this.
> 
> Fair point, but there is no upstream tarball yet as there has been no release.
> For the time being, I've put a comment that describes how to create the tarball
> that's in srpm. If there's no released tarball by the F-11 deadline, we still
> might package a git snapshot as described in
> https://fedoraproject.org/wiki/Packaging/NamingGuidelines#NonNumericRelease.

An alpha release like Simo suggested would be great. A snapshot will be good
enough.

> If you consider this important I might do this also for every round of
> reviewed packages.

You can take your time. I can review the rest and then approve the package
right after you provide a tarball that will comply with guidelines.

> > MUST: Every binary RPM package (or subpackage) which stores shared library
> > files (not just symlinks) in any of the dynamic linker's default paths, must
> > call ldconfig in %post and %postun.
> 
> /usr/lib/sssd/ is not linker's default path. The symlinks are created manually
> during "make install". If we want to have them created via ldconfig, we should
> drop a config file to /etc/ld.so.conf.d/. But that'd work for rpm only anyway.
> 
> > MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1),
> > then library files that end in .so (without suffix) must go in a -devel
> > package.
> 
> So we would have a -devel subpackage that contains just the two symlinks? It's
> certainly doable, but I wonder if we need to ship these versionless symlinks at
> all..

OK.

> If you're trying to build rawhide packages on F-10 host machine in mock, keep
> in mind that there is a bug mock that prevented doing so (#487430). Maybe the
> quickest way now is to grab some rawhide box..  

Ah, then I'm lucky, I'm hitting something else :-)

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.