Bug 1400592 - Rename subpackage pyrpkg to python2-rpkg
Summary: Rename subpackage pyrpkg to python2-rpkg
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: rpkg
Version: 24
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: cqi
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1441588
TreeView+ depends on / blocked
 
Reported: 2016-12-01 14:53 UTC by Pavol Babinčák
Modified: 2017-05-18 15:03 UTC (History)
8 users (show)

Fixed In Version: rpkg-1.49-2.fc26 rpkg-1.49-2.fc25 rpkg-1.49-2.fc24 rpkg-1.49-2.el7 rpkg-1.49-2.el6
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-05-18 15:03:24 UTC


Attachments (Terms of Use)
Patch to place rpkg under /usr/bin again (2.45 KB, patch)
2017-05-18 08:51 UTC, clime
no flags Details | Diff
1279930: Patch to place rpkg under /usr/bin again (1.67 KB, application/mbox)
2017-05-18 08:57 UTC, clime
no flags Details

Description Pavol Babinčák 2016-12-01 14:53:07 UTC
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

Comment 1 cqi 2016-12-01 15:54:00 UTC
> 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. :)

Comment 2 Pavol Babinčák 2016-12-01 15:56:08 UTC
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?

Comment 3 cqi 2016-12-02 00:26:28 UTC
> Do you want a separate bug for that?

No. This bug is enough.

Comment 4 Lubomír Sedlář 2016-12-05 06:34:22 UTC
Here is relevant section of packaging guidelines for renaming packages:

https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages

Comment 5 Fedora End Of Life 2016-12-20 21:43:52 UTC
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.

Comment 6 Pavol Babinčák 2016-12-21 13:48:46 UTC
Yep, this is still an issue.

Comment 7 Fedora Update System 2017-03-31 04:58:10 UTC
rpkg-1.49-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-d9d93502a4

Comment 8 Fedora Update System 2017-03-31 04:58:53 UTC
rpkg-1.49-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-8f90ef2439

Comment 9 Fedora Update System 2017-03-31 04:59:50 UTC
rpkg-1.49-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2017-266738a3db

Comment 10 Fedora Update System 2017-03-31 05:00:43 UTC
rpkg-1.49-2.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-5d0bd36b1a

Comment 11 Fedora Update System 2017-03-31 05:03:25 UTC
rpkg-1.49-2.el6 has been submitted as an update to Fedora EPEL 6. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-f3048d9dc3

Comment 12 Fedora Update System 2017-03-31 16:52:01 UTC
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

Comment 13 Fedora Update System 2017-04-01 00:49:32 UTC
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

Comment 14 Fedora Update System 2017-04-01 01:19:30 UTC
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

Comment 15 Fedora Update System 2017-04-01 01:51:40 UTC
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

Comment 16 Fedora Update System 2017-04-01 03:16:11 UTC
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

Comment 17 Fedora Update System 2017-04-06 13:43:31 UTC
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.

Comment 18 Fedora Update System 2017-04-07 03:48:25 UTC
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.

Comment 19 Fedora Update System 2017-04-09 10:19:34 UTC
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.

Comment 20 Fedora Update System 2017-04-17 17:17:21 UTC
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.

Comment 21 Fedora Update System 2017-04-18 00:46:51 UTC
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.

Comment 22 Pavel Raiskup 2017-04-27 14:02:41 UTC
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?

Comment 23 cqi 2017-04-28 03:19:42 UTC
Hi Pavel, why to use rpkg in copr-builder?

Comment 24 Pavel Raiskup 2017-04-28 06:42:30 UTC
What we should instead?  Note that we talk about shell script.

Comment 25 Pavel Raiskup 2017-04-28 06:48:31 UTC
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.

Comment 26 Pavol Babinčák 2017-04-28 08:02:22 UTC
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.

Comment 27 Pavel Raiskup 2017-04-28 08:47:42 UTC
(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?

Comment 29 Pavol Babinčák 2017-04-28 08:59:50 UTC
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.

Comment 30 Pavel Raiskup 2017-04-28 10:40:07 UTC
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.

Comment 31 Pavel Raiskup 2017-04-28 11:50:06 UTC
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).

Comment 32 clime 2017-05-12 08:33:00 UTC
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.

Comment 33 Pavel Raiskup 2017-05-12 08:58:58 UTC
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*.

Comment 34 clime 2017-05-12 11:06:32 UTC
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.

Comment 35 Pavel Raiskup 2017-05-12 11:25:25 UTC
Agreed:  From the 'dist-git' project POV, having "some" distro-agnostic
client tool clearly makes sense.  Thanks for the point!

Comment 36 clime 2017-05-18 08:51:56 UTC
Created attachment 1279930 [details]
Patch to place rpkg under /usr/bin again

Comment 37 clime 2017-05-18 08:54:49 UTC
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.

Comment 38 clime 2017-05-18 08:57:56 UTC
Created attachment 1279932 [details]
1279930: Patch to place rpkg under /usr/bin again

This is the correct patch.

Comment 39 clime 2017-05-18 15:03:24 UTC
Filed Bug 1452202 - Put rpkg client back to /usr/bin and closing this.


Note You need to log in before you can comment on or make changes to this bug.