Bug 1149887

Summary: RFE: Allow defining depended copr projects
Product: [Community] Copr Reporter: Honza Horak <hhorak>
Component: frontendAssignee: Dominik Turecek <dturecek>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: fedora, fedora, Frodox, orion, praiskup
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-06-20 06:12:38 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:

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