Bug 1149887 - RFE: Allow defining depended copr projects
Summary: RFE: Allow defining depended copr projects
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Copr
Classification: Community
Component: frontend
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Dominik Turecek
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-06 20:19 UTC by Honza Horak
Modified: 2020-06-20 06:12 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-06-20 06:12:38 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1164816 unspecified NEW RFE: determine dependencies and build in order 2021-01-20 06:05:38 UTC

Internal Links: 1164816

Description Honza Horak 2014-10-06 20:19:45 UTC
Description of problem:

This RFE originates from discussion at [1], but for better tracking this let's keep it in bugzila.

Problem:
Currently, copr allows to add a link to an arbitrary repo URL that is 
available for installing dependencies during building in copr. Using 
this dependent repo link we are able to build packages in coprA with 
dependencies in another coprB.

However, when enabling only coprA and installing some packages from this 
copr, we can miss some packages from coprB, because those packages are 
not available since coprB is not enabled.

Solution:
We should be able to define dependency between coprs correctly. When 
creating coprA, we would add one or more depended coprs ('userB/coprB') 
instead of repo link. Then all packages from these coprs would be 
available during build, correct buildroots would be used (no need to 
specify variables $releasever and in addition, we would be able to 
provide correct (all) RPMs also when *installing* coprs.

There are several ways how to implement this on the users' side and it is not sure which is the best, so this part needs to be consulted in the community first. However, definition of the dependency itself seems to be necessary in any scenario.

[1] https://lists.fedoraproject.org/pipermail/devel/2014-October/202931.html

Comment 1 Pavel Raiskup 2018-01-16 06:41:29 UTC
There's a pretty generic way of specifying build-dependencies;  we could
reuse this for the runtime dependencies, too, in textarea:

  copr://<user>/<project>
  copr://@group/<project>

I'm afraid of the "security" POV, at least the `dnf copr enable` feature
should wisely inform user about the fact that user trusts not only to that
copr owner but also to other RPM providers..

.. that said, yes - we can also specify generic repo urls for build-time
deps (not only copr://), and I'm not sure how wise it is to allow it here,
too.  Technically, anything from build-time repo can leak into the "trusted"
copr repo itself, so one can consider this equivalently insecure.

Comment 2 clime 2018-04-09 09:23:49 UTC
(In reply to Honza Horak from comment #0)
> Description of problem:
> 
> This RFE originates from discussion at [1], but for better tracking this
> let's keep it in bugzila.
> 
> Problem:
> Currently, copr allows to add a link to an arbitrary repo URL that is 
> available for installing dependencies during building in copr. Using 
> this dependent repo link we are able to build packages in coprA with 
> dependencies in another coprB.
> 
> However, when enabling only coprA and installing some packages from this 
> copr, we can miss some packages from coprB, because those packages are 
> not available since coprB is not enabled.
> 
> Solution:
> We should be able to define dependency between coprs correctly. When 
> creating coprA, we would add one or more depended coprs ('userB/coprB') 
> instead of repo link. Then all packages from these coprs would be 
> available during build

You probably meant during "install" here.

>, correct buildroots would be used (no need to 
> specify variables $releasever and in addition, we would be able to 
> provide correct (all) RPMs also when *installing* coprs.
> 
> There are several ways how to implement this on the users' side and it is
> not sure which is the best, so this part needs to be consulted in the
> community first. However, definition of the dependency itself seems to be
> necessary in any scenario.
> 
> [1] https://lists.fedoraproject.org/pipermail/devel/2014-October/202931.html

Yes, the idea described here and in the thread is very cool. Hopefully, we can get to it ((very)) soon.

Comment 3 Pavel Raiskup 2020-03-19 02:55:41 UTC
https://pagure.io/copr/copr/pull-request/1265

Comment 4 Pavel Raiskup 2020-03-19 02:56:30 UTC
And the dnf-plugins-core counterpart:
https://github.com/rpm-software-management/dnf-plugins-core/pull/388

Comment 5 Pavel Raiskup 2020-06-20 06:12:38 UTC
Went out a few days ago:
https://fedora-copr.github.io//posts/runtime-dependencies


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