[Freeipa-devel] FreeIPA Copr repo plan

Jan Pazdziora jpazdziora at redhat.com
Wed Nov 19 12:22:59 UTC 2014


On Mon, Nov 10, 2014 at 12:07:46PM +0100, Martin Kosek wrote:
> 
> 1) What Copr repos do we want to maintain and what should be the expectations?
> My take:
> 
> a) mkosek/freeipa: latest and greatest *released* FreeIPA. Built for F20+,
> EPEL-7.0. Jan, this is the one you use in the FreeIPA CentOS container, right?
> Does it fit your needs?

It does not install, so no idea.

Both the centos-7 tag of
https://registry.hub.docker.com/u/adelton/freeipa-server/ and
https://registry.hub.docker.com/u/centos/freeipa/ use the IdM in
CentOS 7, not FreeIPA from your copr repo, at this point.

> b) Branch repos: as mkosek/freeipa Copr repo would contain only the latest and
> greatest release, would it make sense to have a Copr repo with *releases* per
> supported branch to give users a choice? I.e.
> * mkosek/freeipa-4.1
> * mkosek/freeipa-4.0

It is not just users having a choice but the ability to quickly check
behaviour on older version when developing or testing regression.

> These repos are there already, but not used consistently. I do not think we
> should build all the dependency chain (too much overhead) for older systems
> (F20/EPEL). But I assume we could at least build the freeipa SRPM itself for
> these systems if it uses "mkosek/freeipa" as additional build root in Copr.

I don't think it's necessary to build dependency chain to the oldest
versions. But if the release was once built on a give OS (as
a nightly, for example), we should be able to keep it, including the
dependencies.

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

Having them into separate copr repos would certainly allow better
insight into (for example) the dependency chains by people who know
how their part should build and install.

Currently when we see a huge dependency tree when installing
freeipa-server package, it might not be immediatelly obvious, what
is causing the possible bloat.

-- 
Jan Pazdziora
Principal Software Engineer, Identity Management Engineering, Red Hat




More information about the Freeipa-devel mailing list