[Freeipa-devel] FreeIPA Copr repo plan

[John Dennis]

On 11/10/2014 06:07 AM, Martin Kosek wrote:

> c) Daily repos Should we deprecate old John's repos 
> (http://www.freeipa.org/page/Downloads#Bleeding_Edge) which is
> difficult to maintain and replace them with Copr ones? I.e. to have
> common repo (e.g. mkosek/freeipa-daily) built for the supported
> Fedoras (F20, F21, rawhide ATM) including dependencies?

Nalin does the actual builds, I noticed he wasn't on the CC list so I
just added Nalin to this reply.

>From what I know of Copr it's a better tool than our homegrown solution.
If you're already doing Copr builds then I don't see much logic in
keeping the old system. It makes sense to me there should be 1 entity
pumping out the builds using the same technology, why duplicate efforts?
Let's use the better technology.

> Should it contain daily master builds for all tracked projects
> (FreeIPA, SSSD, 389 DS, bind-dyndb-ldap)? Or do we simply want to let
> distribute it across projects "mkosek/freeipa-master",
> "someone/sssd-master", "someone/389-ds-base-master? Second option may
> scale better better, the list of such repos may be maintained
> somewhere (freeipa.org wiki).

> 3) Scalability of the approach Some dependencies are more difficult
> to maintain than the others. Especially the PKI ones often required
> custom Java packaging (resteasy-base) or a complicated dependency
> chain (the latest jackson-jaxrs-json-provider). It would be great if
> PKI team helps with this effort, as Lukas proposed. Downside is that
> mkosek/freeipa installation would require 2 Copr repos. But maybe we
> could have a job syncing the PKI build/runtime dependencies directly
> to FreeIPA copr. Whatever works and scale.

I'm not sure I'm a fan of the scattered repo approach simply because
it's hard for end users, too many yum repo configs to manage. One thing
I think did work well with the old setup is the repo contained all the
necessary dependencies which could not be satisfied from the system
repos. I recognize the difficulty of trying to be a build master for a
collection of difficult to build packages. What were we doing with the
old system was to pull packages built elsewhere (i.e. Kevin did the CS
builds) and merge them into the repo thus a user needed only point to
one user, but we weren't responsible for doing builds for everything,
just integrating, this makes the most sense to me.


-- 
John