[Freeipa-devel] FreeIPA 4.1 release preparations

Martin Kosek mkosek at redhat.com
Mon Nov 10 09:18:45 UTC 2014


On 11/10/2014 10:09 AM, Lukas Slebodnik wrote:
> On (09/11/14 10:09), Martin Kosek wrote:
>> On 11/08/2014 02:43 PM, Lukas Slebodnik wrote:
>>> On (20/10/14 16:08), Martin Kosek wrote:
>>>> On 10/20/2014 04:00 PM, Jan Pazdziora wrote:
>>>>> On Mon, Oct 20, 2014 at 03:58:27PM +0200, Petr Vobornik wrote:
>>>>>>
>>>>>> The plan is to release 4.1 and then 4.0.4. Besides usual tarballs, 4.1 will
>>>>>> go into Fedora rawhide, f21-updates-testing and mkosek/freeipa copr repo (to
>>>>>> be usable on F20).
>>>>>
>>>>> And RHEL 7 / CentOS 7?
>>>>
>>>> For now, I would only maintain RHEL/CentOS 7.0 compatibility for main
>>>> "mkosek/freeipa" repo.
>>>>
>>> It is almost 3 weeks from this mail and freeipa-server cannot be installed from
>>> "mkosek/freeipa" repo on  RHEL/CentOS 7.0.
>>>
>>> bash-4.2# yum install freeipa-server
>>> //snip
>>>
>>> ---> Package pki-base.noarch 0:10.2.0-3.el7.centos will be installed
>>> --> Processing Dependency: jackson-jaxrs-json-provider for package: pki-base-10.2.0-3.el7.centos.noarch
>>> --> Finished Dependency Resolution
>>> Error: Package: pki-base-10.2.0-3.el7.centos.noarch (mkosek-freeipa)
>>>            Requires: jackson-jaxrs-json-provider
>>>  You could try using --skip-broken to work around the problem
>>>  You could try running: rpm -Va --nofiles --nodigest
>>>
>>> There were some promises on freeipa-users but nothing has changed.
>>>
>>> Is somebody working on this problem?
>>> Maybe it is another candidate for inegtation tests.
>>>
>>> LS
>>
>> This problem is known, but it is not simple one to solve.
>> jackson-jaxrs-json-provider is a new dogtag Java dependency which broke the
>> package set on EL 7.0 which however brings a lot of and other build/runtime
>> dependencies.
>>
> Agree.
> I just want to find solution and help desperate users on CentOS 7.

+1, me too.

>> Question is how to solve this properly, this still needs some work and
>> discussion to happen as current approach obviously do not scale, as you
>> noticed.
>>
> IMHO, the best solution would be to separate dogtag from freeipa yum repo.
> Pros:
>     * It would reduce dependency in freeipa repo
>     * dogtag team would maintain separate COPR repo for older distributions.
>       (they know better about new dependencies and java packaging)

That makes sense, yes. I was thinking along these lines yesterday too.

> Cons:
>     Two COPR repositories would need to be enabled for installing latest
>     freeipa.

Exactly. With multiple required repos, those may quickly get out of sync with
regards to suppoted architectures or expectations about these repos.

However, if we agree on the expectations with the PKI team, could IPA own
cronjob that would watch PKI Copr repo on specified arches and rebuild it for
the common one using PKI team SRPMs?

Martin




More information about the Freeipa-devel mailing list