#229 [RFE] New command 'importspec'
Opened by praiskup. Modified

Consider that you have (a) spec file and (b) all the sources/patches downloaded in one directory on your box:

$ ls
 foo.spec
 blah.patch
 foo-1.2.3.tar.gz

If the spec file is "valid", that is having 'Patch: blah.patch' and 'Source: foo-%version.tar.gz' specified -- it be pretty deterministic request to ask for importing foo.spec into the module. At least if you trivially used rpmbuild -bs and then rpkg import internally.


I like the idea of this new command importspec. rpmbuild -bs should be the good choice than doing that by rpkg itself, as all potential problems can be detected and caught by rpmbuild. import uploads files by default, this new command would have same default behavior by reusing import internally.

In addition, would import --from-spec [file] also make sense?

@cqi wrote:

In addition, would import --from-spec [file] also make sense?

This sounds good to me, too.

As discussed in https://pagure.io/copr/copr/issue/102, it is necessary to be
able to specify "remote spec file" (from the CWD point of view), so this should
be actually working:

$ pwd
/tpm/test-project
$ ls -1 ../origin-project
blah.spec
first.patch
second.patch
tarball.tar.gz
$ fedpkg import --from-spec ../origin-project/blah.spec
... everything stashed ...

One could argue that sources/patches could be in different directory, but
I would only expect "valid" dist-git source tree layout; where patches/sources are in
the same directory as the specfile (at least in the initial phase of implementation).

Metadata Update from @cqi:
- Issue set to the milestone: 1.51

Metadata Update from @cqi:
- Issue set to the milestone: NEXT (was: 1.51)

Metadata Update from @cqi:
- Issue set to the milestone: 1.58 (was: NEXT)
- Issue tagged with: RFE

This issue has been unresolved for more than a year, and is going to be closed within a week if no further action is taken. If you feel this is in error, please contact me.
This is a cleaning process suggested by Jay Greguske. Copy of this ticket was already closed in JIRA tracker.

Metadata Update from @onosek:
- Issue set to the milestone: None (was: 1.58)

Metadata