On 08/18/2015 11:37 AM, Jan Cholasta wrote:
On 17.8.2015 16:47, Milan Kubík wrote:
On 08/17/2015 04:44 PM, Milan Kubík wrote:
On 08/17/2015 10:23 AM, Martin Basti wrote:



On 08/12/2015 01:10 PM, Milan Kubík wrote:
On 08/10/2015 04:41 PM, Jan Cholasta wrote:
Dne 10.8.2015 v 16:03 Milan Kubík napsal(a):



-------- Forwarded Message --------
Subject:     Re: [Freeipa-devel] Unable to install bits from
ipa-4-2 branch
Date:     Mon, 10 Aug 2015 15:55:35 +0200
From:     Jan Cholasta <jchol...@redhat.com>
To:     Milan Kubík <mku...@redhat.com>
CC:     Martin Kosek <mko...@redhat.com>



Dne 10.8.2015 v 15:31 Milan Kubík napsal(a):
On 08/10/2015 03:22 PM, Jan Cholasta wrote:
Dne 7.8.2015 v 09:17 Martin Kosek napsal(a):
On 08/07/2015 08:46 AM, Jan Cholasta wrote:
Dne 7.8.2015 v 08:44 Martin Kosek napsal(a):
On 08/06/2015 05:26 PM, Milan Kubík wrote:
Hi list,

I just noticed that the bits built from ipa-4-2 branch
cannot be
installed.
The freeipa packages built have version such as
freeipa-server-dns-4.2.0-0.20150806083844Zjenkins9git2812242.fc22.x86_64



The version check in the spec file makes the server-dns package
obsolete the
server package from tha same build.
The cause is the commit [1]. This issue blocks us from
running tests
on ipa-4-2
branch.

Should we bump the minor version on this branch to 4.2.1?

[1]:
https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=f555fe95dba9ec453fa10f160089dcc5404f724a







Cheers,
Milan

Why does the spec calls for

# upgrade path from monolithic -server to -server + -server-dns
Obsoletes: %{name}-server <= 4.2.0

and not for

# upgrade path from monolithic -server to -server + -server-dns
Obsoletes: %{name}-server < 4.2.0

? Is that the root cause of these issues?

AFAIK this would break updates from 4.2.0 to 4.2.1.

I wonder how it could break the upgrade...


Patch attached.

This won't help as long as we build something like
freeipa-server-dns-4.2.0-0.20150810111037Zjenkins11gitad6a87e

Right. Updated patch attached. It will break updates from
pre-server-dns
git builds, but install should be fine.

--
Jan Cholasta


ACK, thanks.

Self-NACK, as this also breaks updates from freeipa-4.2.0-0 from
the freeipa-4.2 COPR.

Updated patch attached.

Hi,

thanks for the patch. It works as far as updating from 4.1, the copr
build
(correctly replaces freeipa-server package) as well as upgrade from
earlier build from repository.

If there are no objections, ACK from me.

Milan

Pushed to ipa-4-2: 5d5240b9db3b9e6f29351c65272a363b253cd2d3
Ok, while checking this manually it seemed to work, the jenkins build
names the package in a way that  produces this error. The patch has no
effect in automation, unfortunatelly. The build on jenkins adds the
release version, when built manually, the name is
xyz.4.2.0.DATE+hash-string.

Error: package freeipa-server-dns-4.2.0-0.20150817084102Zjenkins28git5d5240b.fc22.x86_64 obsoletes freeipa-server <= 4.2.0.0 provided by freeipa-server-4.2.0-0.20150817084102Zjenkins28git5d5240b.fc22.x86_64

Late answer to Lukas, this is n:m scenario. I'm not sure what to do if one subpackage retains the original name, though.



That being said, I can change the schema by which jenkins marks release
version on the rpms it builds.
This will provide a hacky way around this issue by creating
4.2.0.2015... provided by the timestamp.

This is the scheme used by "make rpms", so I'd say go for it. Otherwise, changing the "Obsoletes" line to:

Obsoletes: %{name}-server <= 4.2.0.0-0.0

should fix it.

The released packages don't really use that much numbers.
Just freeipa-component-MAJOR.MINOR.RELEASE-PKGREL.arch... First three defined by freeipa, -X by fedora. Therefore, I don't think we should use 4.2.0.0.

In jenkins I have changed it to use IPA_VERSION_IS_GIT_SNAPSHOT=yes which changes the naming schema allowing this hack to work. The jobs weren't using the VERSION script this way before, however.

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to