On 10/03/2014 08:24 AM, Bohuslav Kabrda wrote:
> ----- Original Message -----
> > Hi all,
> >
> > I have a proposal that would change how dependencies are defined in copr:
> >
> > 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.
>
> 3) (And I think that I've already heard this idea from someone) I think it'd
> be better to:
> - Put the copr repofiles into RPMs and put all these RPMs in a single repo.
> - These repofile RPMs can depend on each other.
> - "dnf copr enable" installs an RPM from this repo.
> - When a dependency between repos change, repofile RPMs will be updated. When
> user runs "dnf update", he will get the new repofile RPM build, which will
> have dependencies changed properly - so dnf will install these, too.
>
> > 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
>
> I think that 3) is ok from this POV. The problem here can be, that in 3), dnf
> would on update technically enable other copr repos without explicit user
> approval. I'm not sure whether this is a problem or not, though.
Well, dnf/yum should show you what will be installed/enabled as dependencies,
so the user is kind of informed what extra repos will be installed and enabled.
>
> > gets changed (on the server's side).
> >
> > Let's discuss this a bit, I'm eager to hear your opinions.
> >
> > Cheers,
> > Honza
>
--
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience
PGP: 1D9F3C2D
Red Hat Inc. http://cz.redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
