Bug 1519590
| Summary: | Review Request: module-build-service-copr - Copr plugin for the Module Build Service | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jakub Kadlčík <jkadlcik> |
| Component: | Package Review | Assignee: | Robert-André Mauchin 🐧 <eclipseo> |
| Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | eclipseo, jkadlcik, msuchy, package-review, rbean |
| Target Milestone: | --- | Flags: | eclipseo:
fedora-review+
|
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-01-10 17:13:52 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Jakub Kadlčík
2017-12-01 00:46:00 UTC
Spec URL: https://copr-be.cloud.fedoraproject.org/results/@copr/copr-dev/fedora-27-x86_64/00682753-python-module-build-service-copr/module-build-service-copr.spec SRPM URL: https://copr-be.cloud.fedoraproject.org/results/@copr/copr-dev/fedora-27-x86_64/00682753-python-module-build-service-copr/python-module-build-service-copr-0.1-1.git.16.0336ed9.fc27.src.rpm > %if 0%{?fedora} > %global with_python3 1 > %else > %global with_python3 0 > %endif %if 0%{?rhel} && 0%{?rhel} <= 7 %bcond_with python3 %else %bcond_without python3 %endif * Move Requires/BuildRequires under appropriate subpackages > %{python3_sitelib}/* Be more specific here. > * Tue Nov 28 2017 Jakub KadlÄÃk <frostyx> 0.1-1 Version is wrong, encoding is wrong. - URL is wrong. It should be: URL: https://pagure.io/copr/%{srcname} - Explain in a comment how to generate the Source0 tgz - If you package a snapshot, the Release tag should be in the format: Release: 0.1.20171201git0eec290%{?dist} See: https://fedoraproject.org/wiki/Packaging:Versioning#Snapshots Spec URL: https://copr-be.cloud.fedoraproject.org/results/@copr/copr-dev/fedora-27-x86_64/00683703-module-build-service-copr/module-build-service-copr.spec SRPM URL: https://copr-be.cloud.fedoraproject.org/results/@copr/copr-dev/fedora-27-x86_64/00683703-module-build-service-copr/module-build-service-copr-0.3-1.fc27.src.rpm Thank you guys for the feedback. No way I would expect it so fast. I've addressed your comments except for > > %{python3_sitelib}/* > > Be more specific here. When I narrow it to the %{python3_sitelib}/module_build_service_copr it complains about unpackaged egg files. I've looked into the docs https://fedoraproject.org/wiki/Packaging:Python_Eggs#Providing_Egg_Metadata_Using_Setuptools and it is done the same way as I have it. I have no philosophical problem with changing the line, but I don't really know how. Try something like:
%{python3_sitelib}/%{srcname}
%{python3_sitelib}/srcname-%{version}-*.egg-info
Ah, thank you, Robert. I tried something like this, but I must have made some typo in it. Spec URL: https://copr-be.cloud.fedoraproject.org/results/@copr/copr-dev/fedora-27-x86_64/00683728-module-build-service-copr/module-build-service-copr.spec SRPM URL: https://copr-be.cloud.fedoraproject.org/results/@copr/copr-dev/fedora-27-x86_64/00683728-module-build-service-copr/module-build-service-copr-0.4-1.fc27.src.rpm The way you update Version/Release is wrong. Version should reflect the version of the app you are packaging, it should not change if upstream version hasn't changed. Release is corresponding to the revision of the SPEC file, i.e. it is incremented when you make change to the SPEC file and reset to 1 when a new upstream is published. It seems you bump the upstream version each time you update the SPEC, this doesn't seem right, you should have a version specific to the module_build_service_copr module that doesn't depend on the SPEC. @Robert He is an upstream. So he can do it. It does not make sense to maintain two spec file for upstream and downstream if he is maintainer of both upstream and downstream. Ok then the package is sound and accepted. |