Idea: Ability to define dependencies between coprs (correctly)

[Tomas Hozza]

On 10/02/2014 05:48 PM, Honza Horak wrote:
> On 10/02/2014 05:18 PM, Pierre-Yves Chibon wrote:
>> On Thu, Oct 02, 2014 at 05:00:40PM +0200, Honza Horak wrote:
>>> 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 basically two ways how to implement this on the users' side:
>>> 1) Simpler, preferred by Mirek, copr maintainer (CC'd):
>>> 'copr' plugin in dnf would include -r option, which would basically
>>> installed all related coprs. That means when running `dnf copr enable -r
>>> userA/coprA`, user would end with two coprs enabled: userA/coprA and
>>> userB/coprB.
>>>
>>> 2) More complicated, preferred by me :) :
>>> copr A repository from example above would not only include RPMs build as
>>> part of this copr, but would include also packages from copr B. That means
>>> that when running `dnf copr enable userA/coprA`, user would not need to
>>> install userB/coprB repository and would have all packages available.
>>>
>>> Both ways struggle with refreshing data:
>>> * in 1) we might need to refresh coprs enabled (on the users' side)
>>> * in 2) we would need to re-create repodata in depended coprA if coprB gets
>>> changed (on the server's side).
>>
>> What about putting the definition of the coprA on the coprB, ie at:
>> https://copr.fedoraproject.org/coprs/pingou/subsurface/repo/fedora-19/pingou-subsurface-fedora-19.repo
>>
>> include the definition of the repo this copr depends on (ok bad example for this
>> specific copr).
>>
>> This way, it's rather clear to the user that the packages are coming from two
>> distinct copr, there no need to change dnf and we don't mix up in one repo
>> packages potentially built by different people.
>>
>> That does imply that existing .repo file might have to be updated.
> 
> Yeah, I like that idea, that would remove some obstacles mentioned for solution
> 1) above. I'm not sure though if the depended coprs can be called the same as
> the original (we would have two similar repos enabled) or we would have to call
> them differently. Just quick test does not show any issues with more repos with
> the same name.
> 
> Honza

Different repos inside a single repo file will be still shown as different
repos when installing a packages from them. Therefore should not cause any problems.

However in thins case it might be worth deciding if such .repo should be named
in a way to express it contains also a "bundle" of dependent repos.

Regards,
-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
Red Hat Inc.                               http://cz.redhat.com