https://bugzilla.redhat.com/show_bug.cgi?id=1107422 --- Comment #3 from Florian "der-flo" Lehner <dev@xxxxxxxxxxx> --- (In reply to Rich Mattes from comment #2) > I've addressed the following: > * Add more detailed descriptions > * Add versioned Requires where available > * Added comments about license breakdown and patch status > * Fixed package ownership issues > * Fixed bugs with breaking the libraries up into separate packages Looks quite good so far :-) > There's a couple of things I'm not sure about: > * The source URL (derived from the commit hash) is needed as per the github > packaging guidelines at > http://fedoraproject.org/wiki/Packaging:SourceURL#Github. I think the > problem with the github "releases" is that they're based on tags, which are > mutable Since the commit revision hash in your spec-file is the same commit revision hash that tags version 1.6.6 upstream, it's much easier to use just the following: Source0: https://github.com/OctoMap/%{name}/releases/tag/v%{version}.tar.gz#/%{name}-%{version}.tar.gz If you package a non-tagged version I totally agree with you. As the your links says: >> If the upstream does create tarballs you should use them as tarballs provide an easier trail for people auditing the packages. > * The ldconfig snippets in post and postun follow the guidelines at > https://fedoraproject.org/wiki/Packaging:Guidelines#Shared_Libraries, I > don't think there needs to be a macro for sbindir (which expands to > /usr/sbin, not /sbin) I recommend to use macros everywhere it's possible. You never know how people change/map/unmap their system. Using macros you are well prepared (even it's not yet in the snippet). -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review