Description of problem: Package rpkg has two subpackages: - pyrpkg - library - rpkg - example client Other client packages (e.g. fedpkg) requires pyrpkg. But because package name is rpkg people are often confused about this and install rpkg instead. Version-Release number of selected component (if applicable): since rpkg-1.15-1.fc15 until now Expected results: Please rename pyrpkg to python2-rpkg. Leave provides pyrpkg in that package though to ensure backwards compatibility for packages. This will help python3 porting later: https://fedoraproject.org/wiki/Packaging:Python
> Leave provides pyrpkg in that package I'm not sure I understand this correctly. There will be only one package named python2-rpkg, that contains both pyrpkg and the example client rpkg. Am I correct? Actually, I like this way. :)
Actually my idea was to rename pyrpkg to python2-rpkg. Set provides: pyrpkg for that package. Regarding rpkg subpackage - I'm tempted to get rid of that in downstream package as it isn't most likely useful for anyone. I've seen some discussion somewhere. Do you want a separate bug for that?
> Do you want a separate bug for that? No. This bug is enough.
Here is relevant section of packaging guidelines for renaming packages: https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Yep, this is still an issue.
rpkg-1.49-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-d9d93502a4
rpkg-1.49-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-8f90ef2439
rpkg-1.49-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2017-266738a3db
rpkg-1.49-2.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-5d0bd36b1a
rpkg-1.49-2.el6 has been submitted as an update to Fedora EPEL 6. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-f3048d9dc3
rpkg-1.49-2.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-d9d93502a4
rpkg-1.49-2.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-5d0bd36b1a
rpkg-1.49-2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-266738a3db
rpkg-1.49-2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-8f90ef2439
rpkg-1.49-2.el6 has been pushed to the Fedora EPEL 6 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-f3048d9dc3
rpkg-1.49-2.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
rpkg-1.49-2.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
rpkg-1.49-2.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
rpkg-1.49-2.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.
rpkg-1.49-2.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
The `rpkg` script is useful for `copr-builder`, and one new mock feature also depends on `rpkg`: https://bugzilla.redhat.com/1441588 https://github.com/rpm-software-management/mock/pull/41 Could we please revert that "remove /bin/rpkg", and perhaps rpkg package?
Hi Pavel, why to use rpkg in copr-builder?
What we should instead? Note that we talk about shell script.
Ah, to actually answer the question: We basically need to "clone" the git repository (an automatized way) and download sources from lookaside cache. With /bin/rpkg it is trivial, for the 5 dist-git instances I know about we only need to have 5 config files and it just works. AFAIK, rpkg script is now also used in released mock, not only copr-builder. And per clime, `copr-builder` is going to delegate this matter to mock soon.
Pavel, I'm wondering if copr-builder will be installed on server or client machines? Koji builders needs to checkout dist-git branch and download sources from lookaside cache. They no longer use fedpkg nor rpkg. Instead https://pagure.io/fedpkg-minimal is used for this. There were two main reasons to switch to shell script: - less dependencies than rpkg (no python nor many other packages that are needed only for other fedpkg/rpkg features) - faster buildroot installation - lower chance of breaking build system with faster development of client tool (fedpkg) fedpkg-minimal cannot be used on client though because its binary (fedpkg) conflicts with client one - fedpkg.
(In reply to Pavol Babinčák from comment #26) > Pavel, I'm wondering if copr-builder will be installed on server or > client machines? Client machines (builders, end-users), read-only; so yeah.. > Koji builders needs to checkout dist-git branch and download sources > from lookaside cache. They no longer use fedpkg nor rpkg. Instead > https://pagure.io/fedpkg-minimal is used for this. Thanks for the info. Could we rename that project to raise "more general-purpose feeling" (e.g. 'rpkg-minimal') and add some trivial ini (crudini e.g.) configuration? Because e.g. Fedora Copr runs 2 dist-git instances, and Internal Copr 3 dist-git instances; copy&paste the script all the time is not very nice ... (btw., what script is used by brew builders?). If that makes sense, we perhaps should switch to use that project in copr (and mock), too. > There were two main reasons to switch to shell script: > - less dependencies than rpkg (no python nor many other packages that are > needed only for other fedpkg/rpkg features) - faster buildroot installation That's good point, we talk about 'mock --buildsrpm', right?
Internally (for Brew) it is called rhpkg-minimal. Unfortunately it doesn't share code base with fedpkg one. There is also no common upstream like rpkg. I believe the reason is lack of resources to make that happen.
Ok, thanks. (In reply to Pavol Babinčák from comment #26) > - less dependencies than rpkg (no python nor many other packages that are > needed only for other fedpkg/rpkg features) - faster buildroot installation This is not a benefit from Copr's POV, because we still want to have the rpkg/rpkg-minimal installed on host /not in mock buildroot/. We re-build SRPM (from dist-git) for-each-chroot. This is probably because it is believed (I don't share this belief, perhaps I'm wrong) that SRPMs are overly OS dependant: - koji builders generate one src.rpm in specific fedora version, and that (noarch) src.rpm is built in buildroots of the same fedora version, even though in a different architectures). - Fedora's Copr OTOH builds against epel-5+ and fedora-25+ (at the time of writing this comment), so it is (maybe) too risky to generate one src.rpm, and build that against all the buildroots.. Then, because each builder needs to generate (os-specific) SRPM from dist-git, and than RPMs from that SRPM, we build both in the same chroot without cleaning the caches after generating SRPM. So (for the purpose of SRPM generation) we can't install `fedpkg-minimal` which might be later in collision with some BuildRequires of the final package.
After off-list discussion with Pavol, we sort of agreed that depending on 'rpkg' was not a good idea in the first place (rpkg was never meant to be tool for use, or at least nobody believed that the package is useful as-is). So the idea now to be discussed with Copr guys is to have `rpkg-simple` or something like that, written so it matches the needs of everybody out there (copr, internal copr, brew, koji). And if that's done right, koji and brew could switch to use those, too. The other option is to provide `rpkg` again as (sub)package, but that's based on Pavol not a good idea (at least the package wouldn't be useful in Koji/Brew workflow, thus not that widely tested...). As I reopened this, I'm taking the liberty to close this now (at least until we'll chat a bit with Copr developers).
Actually, I wanted to promote rpkg as a primary client-side tool for this package of which version 1.0 was recently released: https://admin.fedoraproject.org/pkgdb/package/rpms/dist-git/ I would like to sum up the requirements floating around: For mock-scm plugin, we only need something that is able to download sources from lookaside. For copr-builder package, we need something that can download sources and also upload sources with (at least) https client certs as an authentication method. For the dist-git package, we need a full-fledged command-line client that would be distribution (CentOS, RHEL, Fedora) independent. --- For the last point, rhpkg or fedpkg can also be used with https://admin.fedoraproject.org/pkgdb/package/rpms/dist-git/ although they are distribution-specific.
This is not a good place for such discussions. Sorry. I basically agree that we need to be able to upload sources and commit changes into dist-git (somehow), the distribution-neutral way. The question is however whether we don't want to rather have something like 'copkg' for that, instead of 'rpkg'. Also, 'copkg' seems to be something different from 'rpkg-minimal' idea, those would have completely different use-cases. (In reply to clime from comment #32) > For copr-builder package, we need something that can download sources and > also upload sources with (at least) https client certs as an authentication > method. I don't like the idea of "pushing" changes back from builders to dist-git (copr-builder is designed for builder machines OTOH 'rpkg' and 'copkg' would be more like client tool). It would also complicate configuring the builders ... but more importantly... It is trivial to get root access on builder machine (chroot escape), so allowing builders to "push" something back to dist-git VM would be unacceptable weak point. To the point: Yeah, I agree that `copr-builder` _needs to be_ used for generating the "primary" SRPMs (from github, tito, etc...) so we don't DDOS copr dist-git VM! -> though the final import into dist-git and lookaside cache needs to be done *on dist-git VM*.
Pavel, I think we can discuss it in a COPR-related issue or PR? Anyway, I would like to ask to re-add rpkg as an (example) client to dist-git into Fedora. I write about it in a blog-post about the new dist-git package and I think it would be good to have a basic client that does not contain any distro-specific tweaks.
Agreed: From the 'dist-git' project POV, having "some" distro-agnostic client tool clearly makes sense. Thanks for the point!
Created attachment 1279930 [details] Patch to place rpkg under /usr/bin again
Ok, I can see it is being placed into /usr/share/rpkg/examples now. I really would like to see it being returned into /usr/bin/ as a general-purpose dist-git client. I submitted a patch for it. Please, take a look.
Created attachment 1279932 [details] 1279930: Patch to place rpkg under /usr/bin again This is the correct patch.
Filed Bug 1452202 - Put rpkg client back to /usr/bin and closing this.