https://bugzilla.redhat.com/show_bug.cgi?id=1295115
--- Comment #12 from Dave Johansen <davejohansen(a)gmail.com> ---
(In reply to jeremy.fergason from comment #11)
That was a big step in the right direction, but here's some more comments:
- Release is usually just an integer (i.e. 1 instead of 0.1) and it's usually
best to increment it with each change so that it's easier for reviewers to
compare different versions
- As Meng pointed out, the Source* tags should use macros so that only a
single value has to be changed when a new release is made
- Get rid of # in Source* tags and use original names in source .rpm
- Are versions listed in BuildRequires "real" (i.e. listed in Swift
documentation and/or the true minimum version required)?
- All patches needs to have at least an issue opened upstream and documented
in the .spec file what the expected resolution is (
https://fedoraproject.org/wiki/Packaging:Guidelines#All_patches_should_ha...
)
- I don't believe the "cd .." is necessary at the end of %prep
- Add version to changelog entries (
https://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs )
The one thing that I don't know how to do is deal with the
/usr/lib vs
/usr/lib64 issue. I just redefined the macro; is this the way to deal with
that?
Is this actually building Swift or just unpacking a pre-built binary?
If it's just a pre-built binary, then this package cannot be packaged for
Fedora (
https://fedoraproject.org/wiki/Packaging:Guidelines#No_inclusion_of_pre-b...
).
If it's actually building Swift, then you should open a ticket upstream and get
the issue resolved in their build system so it can play nice with Fedora.
--
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