[Freeipa-devel] FreeIPA Copr repo plan

[Lukas Slebodnik]

On (10/11/14 07:53), John Dennis wrote:
>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
mkosek/freeipa contains 44 different packages.
and approximately 1/4 of them are related just to dogtag for rhel7

>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
It *is not* possible to merge one COPR repo into another.
It is possible to add another yum repo into build dependencies in COPR
but it usually mean you will need to enable 2nd repo for installation of
freeipa as well.

LS