https://bugzilla.redhat.com/show_bug.cgi?id=1418371 --- Comment #3 from Dusty Mabe <dustymabe@xxxxxxxxxx> --- (In reply to Jan Chaloupka from comment #2) > > Issues: > > ======= > > - Package installs properly. > > Note: Installation errors (see attachment) > > See: https://fedoraproject.org/wiki/Packaging:Guidelines > > > > This fails because these two packages are needed > > > > golang(github.com/karlseguin/expect) > > Provided by different that is on review Yep. I was just trying to explain why it failed :) > > > golang-github-karlseguin-ccache-devel > > Provided by this package itself +1 > > > > > > > > > ===== MUST items ===== > > > > Generic: > > [x]: Package is licensed with an open-source compatible license and meets > > other legal requirements as defined in the legal section of Packaging > > Guidelines. > > [x]: License field in the package spec file matches the actual license. > > Note: Checking patched sources after %prep for licenses. Licenses > > found: "MIT/X11 (BSD like)", "Unknown or generated". 15 files have > > unknown license. Detailed output of licensecheck in > > /home/vagrant/1418371-golang-github-karlseguin-ccache/licensecheck.txt > > [x]: License file installed when any subpackage combination is installed. > > [ ]: Package must own all directories that it creates. > > Note: Directories without known owners: /usr/share/gocode/src, > > /usr/share/gocode, /usr/share/gocode/src/github.com > > > > These are directories owned by golang rpm - should we require golang be installed? > > Does not make much sense to install devel source code without the compiler > so the dependency on golang is intentionally ignored +1 > > > > > [ ]: Package does not own files or directories owned by other packages. > > Note: Dirs in package are owned also by: > > /usr/share/gocode/src/github.com/karlseguin(golang-github-karlseguin- > > expect-devel) > > > > Not sure what to do about this > > Ignore it. The spec looks fine. If not, that is something that needs to be > fix globally. hmm, ok, +1 > > > > > ===== SHOULD items ===== > > > > Generic: > > > > [x]: Latest version is packaged. > > > > The commit from this package matches the latest released version: > > 2.0.2 == a2d6215 > > https://github.com/karlseguin/ccache/releases/tag/v2.0.2 > > > > We don't package latest releases by default (unless requested) since > projects need particular commits which do not have to be backward compatible > with the latest releases. interesting. I would have thought we wanted to use release numbers instead of git commits if possible. This commit does match the latest released version. What you are saying is that if etcd all of a sudden now needs some arbitrary commit then it wouldn't be good to have a "version" other than 0 for this rpm? What happens if another package needs this dependency and needs it at a different git commit? -- 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 To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx