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/pin...
>
> 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.