On Thu, Oct 02, 2014 at 05:48:20PM +0200, 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.
As long as they point to the same url, I don't think having multiple definition
of the same repo is a problem :)
Pierre
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
