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@xxxxxxxxxx> 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review