Some questions around coprs

[Kevin Fenzi]

On Thu, 05 Dec 2013 12:52:36 +0100
Miroslav Suchý <msuchy at redhat.com> wrote:

> On 12/04/2013 09:20 PM, Kevin Fenzi wrote:
> > 1. Do we even want to persue this?
> 
> Not my priority. But if somebody will be willing to do it, then you
> are welcome.
> 
> > 2. If so, do we have any ideas how signing copr packages could work?
> 
> I did not investigated it yet (again not priority right now) but
> probably obs-sign:
> http://en.opensuse.org/openSUSE:Build_Service_Signer
> https://github.com/openSUSE/obs-sign
> or sigul:
> https://fedoraproject.org/wiki/User:Mitr

I've not looked closely at obs-sign, but of course if we wanted to use
it, we would need to package it up, etc. There's still a lot of
questions I would have around where and how the keys are stored, what
it uses to determine what to sign, etc. It's really easy to get this
stuff wrong. :) 

Sigul has no ability I know of to sign anything without certs and
passphrases (ie, there is no non interactive mode). Also, I would be
very strongly against trying to add it to our existing sigul server,
and I am not too trilled about the idea of running more sigul
servers. ;) 

> > 3. Mirroring doesn't seem like it would be that hard, just rsync off
> > the repos and push them out in our regular mirroring system. Could
> > be a fair bit of churn tho, and there's no set schedule, so we
> > would have to decide on frequency, etc.
> 
> Copr is just starting. Not so much users right now. I do not think we
> *need* mirroring right now. I would put this on back burner and
> revisit this question in ~9 months. But again - if somebody is
> willing to configure it, then he is welcome.

Right, but the reason this came up in the fesco meeting is if we point
_ALL_ of our users at some coprs, that could well be more load than a
single point can handle. 
 
> > 4. If coprs moves to being inside koji, could we at that point have
> > a better time with these needs?
> 
> I think, that it does not matter.
> 
> > 5. Perhaps we could propose some kind if pergatory type setup
> > between coprs (experemental, just builds, may set your house on
> > fire, may update incompatibly every day) and fedora repository
> > packages (with all the updates guidelines, reviews, etc).
> 
> Whoa! That is completly Fedora.next hidden in this sentence :)

:) 
 
> We are preparing something like this for SCL right now:
> https://www-dev.softwarecollections.org/en/directory/new/
> Note: ^ this may or not work, this is dev instance under heavy
> development. It is focused on SCL only.
> This will import SCL from Copr and allow to go through some kind of
> review. And reviewed collections will get some kind of publicity.
> This is sooo fresh that I hesitate to anticipate anything. But if
> this will succeed, we can do something similar in higher scale with
> all projects on Copr.

ok. Sounds interesting. 
 
> > Possibly related to this: I wonder if copr could grow a 'meta repo'
> > that has all the repodata of all existing coprs. Then you could just
> > enable one thing and be able to install any coprs?
> 
> Yes. I have in plan to provide such thing. Unfortunately according to
> yesterday FesCO meeting this could not be shipped in Fedora itself.
> At least not yet.

Right, but it would make people wanting to use coprs happy now. Ie,
right now I have to go to the copr web interface, look around and see
what things are interesting, download them and install them one by one. 
If I had a 'fedora-copr.repo' that contained all projects I could 'yum
update' the ones I already have installed easily, or 'yum
--disablerepo=\* --enablerepo=fedora-copr list' to see what new
packages are around. I wouldn't have to search or dig via the web
interface. 

Of course updating a master repo with metadata could be anoying for
locking type issues (if copr a and b finish at the same time, etc). 

Just a thought to make it more accessable now. ;) 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20131206/5f54cccd/attachment.sig>