Idea: Ability to define dependencies between coprs (correctly)

Bohuslav Kabrda bkabrda at redhat.com
Fri Oct 10 10:48:52 UTC 2014


----- Original Message -----
> On 10/03/2014 04:24 PM, Bohuslav Kabrda wrote:
> > 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.
> 
> Using the existing dependency management system sounds good to me. How
> would this interact with/be distinct from the Fedora Playground idea?
> (which was the last place I saw the repo-of-repo-files idea come up)

I think that the main distinctions from Playground are
- the "advertisment" that Fedora should give Playground (it should generally be safe to install packages from Playground)
- Playground packages should, in time, get some sort of AutoQA

I think that the main distinction between normal Copr repos and repos in Playground should be in quality and guarantees that we provide; the (dependency) mechanism should be the same.

Slavek

(Sorry it took so long to respond, this have gotten burried in my mailbox)

> Cheers,
> Nick.
> 
> --
> Nick Coghlan
> Red Hat Hosted & Shared Services
> Software Engineering & Development, Brisbane
> 
> HSS Provisioning Architect


More information about the env-and-stacks mailing list