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



--- Comment #30 from Cristian Le <[email protected]> ---
- `%bcond_*` are quite confusing indeed. If you do not port it to epel8 (don't
know why you would at this time), please use `%bcond (option) (default_value)`
instead
- I try to stay away from sourceforge, but can't you use `Source0` pointing to
`https://sourceforge.net/projects/linux-gpib/files/linux-gpib%20for%203.x.x%20and%202.6.x%20kernels/%{version}/linux-gpib-%{version}.tar.gz`?
I took it from looking at what other spec files with sourceforge do [1]
- Getting a clean git archive is of course also encouraged ever since the libxz
saga. I just don't know if sourceforge can automatically provide one.
`%forgemeta` at least is not aware of one, but if you could find one out, do
let us know.
- Note that the git archive contains the files of the `linux-gpib-kernel`, so
you cannot use that as a source until the firmware parts are cleared
- If you are using a git snapshot, please follow the snapshot naming guidelines
- Please use `%autorelease`/`%autochangelog` [3] unless you have reasons not
to. It helps other Fedora maintainers
- `linux-gpib` and others are not a known package in Fedora, right? please
remove the Obsoletes
- Have you confirmed with upstream that the license is `GPL-2.0-or-later` or
`GPL-2.0-only`? Afaik the distinction cannot be made from the license text
alone since those are identical
- What are the reasons for all of the `%bcond_*`. Usually these are used to
break circular dependencies or if a feature often breaks
- Please use `%autosetup` or at least `%autopatch` instead of manual `%patch`
commands
- Using `3` instead of `%{python3_pkgversion}` is sufficient and more readable.
The latter is used for systems like centos where they can have a secondary
python version. Unless it is requested to use `%{python3_pkgversion}`, please
do not use it eagerly
- Please build the manpages regardless of `%with_docs`
- Conversely, consider if the non-man documentations are really necessary and
worth the effort to maintain. Latex dependencies can be quite heavy
- The `%bcond` do not gate the `BuildRequires` properly
- For python packages you are supposed to use `%pyproject_buildrequires`
instead of adding dependencies like `pyproject-rpm-macros` manually [4]. See
other python projects for other macros that you should be using
- Please use a macro for the SOVERSION instead of the `.so.*` glob
- Are the `%ldconfig` parts necessary, i.e. do other libraries expect it to be
loaded as if they were installed in `/usr/lib64`?
- The `rm ..` in %postun is a big no-no. For that matter any scriplets should
be avoided as much as possible
- Please drop all of the comments separating the sections and instead use 2
newlines when you switch to a new section. Current form can get quite hard to
read due to non-standard comments on section separators
- Please confirm that all the `find %{buildroot} -delete` are necessary. If so
please report it to upstream because that is a bug
- The comment about `EPEL7` does not apply, epel7 is no longer buildable in
either Fedora or copr
- Please confirm the providence of all the Source/Patch files
- The link to the tcl comment is dead. Please use the packaging guideline
instructions instead

[1]:
https://sourcegraph.com/search?q=context:global+file:%5C.spec%24+sourceforge&patternType=keyword&sm=0
[2]:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_snapshots
[3]: https://fedora-infra.github.io/rpmautospec-docs/index.html
[4]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python
[5]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Tcl


-- 
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
https://bugzilla.redhat.com/show_bug.cgi?id=2430590

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202430590%23c30

-- 
_______________________________________________
package-review mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it: 
https://forge.fedoraproject.org/infra/tickets/issues/new

Reply via email to