Idea: Ability to define dependencies between coprs (correctly)

Nick Coghlan ncoghlan at
Fri Oct 3 08:21:13 UTC 2014

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)


Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane

HSS Provisioning Architect

More information about the env-and-stacks mailing list