Bug 1475847 - Use pyrpkg's "import" for srpm imports, don't re-implement
Use pyrpkg's "import" for srpm imports, don't re-implement
Status: CLOSED NOTABUG
Product: Copr
Classification: Community
Component: backend (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Suchý
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-27 09:19 EDT by Pavel Raiskup
Modified: 2017-12-19 02:22 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-03 09:31:06 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Pavel Raiskup 2017-07-27 09:19:30 EDT
Historically we used 'pyrpkg' (alternative to fedpkg import) for importing
uploaded srpms (or srpms pointed to by url).

Now, copr reimplements this itself (extracts that by rpm2cpio, reading the
list with cpio, removing old files from distgit, etc., etc..).

This is architectonic issue and maintenance disaster;  please implement
the functionality in pyrpkg so we don't duplicate the efforts or (if you
plan to experiment in Fedora Copr) please provide an option so I can have
limited feature set (but using the proper tools).
Comment 1 clime 2017-08-03 09:31:06 EDT
That would mean we would again need to build srpms on copr-dist-git or have two ways of importing - one directly from downstream or upstream repo and another from a srpm. The current approach has an advantage of utilizing only one way of doing things. If the functionality we need was present in pyrpkg, then we would be able to use it. It is not however and won't be in near feature.

This is not a bug, nor a feature request, however. It is just 'how-to' do something.
Comment 2 Pavel Raiskup 2017-12-19 02:22:35 EST
(In reply to clime from comment #1)
> That would mean we would again need to build srpms on copr-dist-git

Why?  First the builders still provide srpms, which are imported on dist-git
side.  This bug report is only about this "import" issue.  Second misusing
srpm archive for transport between builder <-> distgit is another issue --
but replacing "srpm import" (on dist-git side) by "tarball" import
or by plain "rsync" from backend (or even builder!) would also fix this
issue an elegant way...

> or have two ways of importing - one directly from downstream or upstream
> repo and another from a srpm.

This is natural and good because you actually don't have to implement srpm
import at all when it is already done by pyrpkg.

> The current approach has an advantage of utilizing only
> one way of doing things. If the functionality we need was present in pyrpkg,
> then we would be able to use it. It is not however and won't be in near
> feature.

Proposal needed I guess!  That's what should have been already done :-)

> This is not a bug, nor a feature request, however. It is just 'how-to' do
> something.

Duplicating efforts is bug in fedora ecosystem.  I just opened
against the culprit component.  Feel free to reopen.

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