Bug 1452202
Summary: | Put rpkg client back to /usr/bin | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | clime | ||||
Component: | rpkg | Assignee: | cqi | ||||
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 26 | CC: | cqi, dennis, lsedlar, pbabinca, praiskup, s | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2017-07-27 21:12:21 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
clime
2017-05-18 14:26:27 UTC
upstream is at https://pagure.io/rpkg/ it was a very intentional decision to remove /usr/bin/rpkg. can you explain your use cases for it please? Yes, upstream is at pagure.io but spec that decides where rpkg resides is in "downstream" here: https://src.fedoraproject.org/cgit/rpms/rpkg.git/tree/rpkg.spec. Recently, a new dist-git package (v1.0) has been released (upstream is at https://github.com/release-engineering/dist-git) and for this package, the recommended command-line client is rpkg. That's basically why I need it back. The dist-git package is free of anything distro-specific and can be used to maintain arbitrary collections of (s)rpm packages. As such, it needs a non-distro specific (in RHEL-based world) client, which is 'rpkg'. The dist-git package is in Fedora and EPEL7 and the client could be there as well. (In reply to clime from comment #2) > Yes, upstream is at pagure.io but spec that decides where rpkg resides is in > "downstream" here: > https://src.fedoraproject.org/cgit/rpms/rpkg.git/tree/rpkg.spec. > > Recently, a new dist-git package (v1.0) has been released (upstream is at > https://github.com/release-engineering/dist-git) and for this package, the > recommended command-line client is rpkg. That's basically why I need it back. I'm curious from where you get the information of rpkg is the recommended command line client to interact with dist-git. I haven't see anywhere to tell that, at least in https://fedoraproject.org/wiki/Package_maintenance_guide, fedpkg should be the right one. (In reply to cqi from comment #3) > (In reply to clime from comment #2) > > Yes, upstream is at pagure.io but spec that decides where rpkg resides is in > > "downstream" here: > > https://src.fedoraproject.org/cgit/rpms/rpkg.git/tree/rpkg.spec. > > > > Recently, a new dist-git package (v1.0) has been released (upstream is at > > https://github.com/release-engineering/dist-git) and for this package, the > > recommended command-line client is rpkg. That's basically why I need it back. > > I'm curious from where you get the information of rpkg is the recommended > command line client to interact with dist-git. I haven't see anywhere to > tell that, at least in > https://fedoraproject.org/wiki/Package_maintenance_guide, fedpkg should be > the right one. Well, fedpkg is the client to use with Fedora DistGit which is richer if compared to the dist-git package (in addition to it, there is bodhi integration and pkgdb integration and also download path contains hashtype). It's just that rpkg as a tiny wrapper around pyrpkg is well suited to be a client of choice for the https://admin.fedoraproject.org/pkgdb/package/rpms/dist-git/ which is different from what Fedora uses in production at the moment. > I'm curious from where you get the information of rpkg is the recommended
> command line client to interact with dist-git.
Good point, I believe it is just matter of documenting it
properly in dist-git project documentation.
I agree that we need to have distro-agnostic tool -- and that's not
`fedpkg` definitely. `rpkg` is neither distro agnostic (more like rhel
oriented) though that's the closest option.
What's the status here, please? (In reply to clime from comment #2) > Yes, upstream is at pagure.io but spec that decides where rpkg resides is in > "downstream" here: > https://src.fedoraproject.org/cgit/rpms/rpkg.git/tree/rpkg.spec. Not entirely sure what you mean here. the rpkg command afaik should be removed entirely. > Recently, a new dist-git package (v1.0) has been released (upstream is at > https://github.com/release-engineering/dist-git) and for this package, the > recommended command-line client is rpkg. That's basically why I need it back. /usr/bin/rpkg was only ever supposed ot be a reference implementation that existed because fedpkg, centpkg and other implementations imported and overloaded the functions in order to do their work. we are attempting to make rpkg be a library providing the core functionality and to improve the design or everything. > The dist-git package is free of anything distro-specific and can be used to > maintain arbitrary collections of (s)rpm packages. As such, it needs a > non-distro specific (in RHEL-based world) client, which is 'rpkg'. The > dist-git package is in Fedora and EPEL7 and the client could be there as > well. each individuaal implementation is expected to come up with their own tooling based on rpkg in order to work with dist-git. sounds like the upstream dist-git maintainers need to communicate with us a bit more and we can work to fix the documentation gap. > sounds like the upstream dist-git maintainers need to communicate with
> us a bit more and we can work to fix the documentation gap.
It rather sounds like nobody listens to the requests.. This is not about
documenting something in pyrpkg but about allowing end-users to just
deploy basic dist-git scenario without requiring them to create their own
packages (the removed 'rpkg' script was convenient enough). Of course
if 'rpkg' is not enough, users can overload some internal methods of
pyrpkg (uhh!) to do their work ...
I think, this has been resolved by Bug 1460917 - Review Request: rpkg - Command-line client tool to DistGit. |