----- 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