04.05.2020 09:55, Dan Čermák пишет:

Hi Jason,

Jason Craig writes:

...

I'm trying to update the python-ZODB[1] package so that it will build and doesn't get dropped from e.g. Leap 15.2. The basic problem is that a test (or possibly multiple tests) started failing with the latest version of python-transaction. This problem is fixed upstream but there hasn't been a new version of ZODB released with the fix in it.

So I'm using a git revision as the source for the package, but this raises the question of what to do with the version number of the package. Reading some documentation[2], it would appear I should use a version like "5.5.1+git56", but this causes RPM to not find the egg-info directory in %files because the version specified in setup.py is "5.6.0.dev0".

So should I a) use version 5.5.1+git56, change the %files section so it picks up the egg-info directory or b) use version 5.6.0.dev0, but then when 5.6.0 is released upstream wouldn't RPM think that 5.6.0.dev0 is still the newer version? c) do something else.

Unless upstream has specifically released 5.6.dev0, I would go with 5.5.1+git%{short_commit}

Commits are unordered, are not they? You need something monotonically increasing to make sure next release actually has high version. Something like git-describe output which nicely piggy-backs on the latest release and is always lower version than next release.

...

Also, the GitHub tarball unzips into a directory named with the commit SHA. Is there a best practice for how to handle this with %setup -n? Just change it manually and change it back to use the package's version later? Should I %define something with the revision and use that macro?

This is what I usually do in these cases: --8<---------------cut here---------------start------------->8--- %global commit $LONG_HASH %global short_commit $SHORT_HASH

# snip

Version: 5.5.1+git%{short_commit} Source0: %{url}/archive/%{commit}.zip

# snip

%prep %autosetup -n %{name}-%{commit} --8<---------------cut here---------------end--------------->8---

and revert back to the old state once upstream makes a "real" release.

Note that while this might be acceptable for Factory, it could be an issue for Leap, as 15.2 is afaik already in the beta and everything is expected to be pretty stable (and not pre-release).

Cheers,

Dan

On Mon, May 4, 2020 at 3:12 AM Dan Čermák wrote:

Andrei Borzenkov writes:

...

04.05.2020 09:55, Dan Čermák пишет:

...

Hi Jason,

Jason Craig writes:

...

I'm trying to update the python-ZODB[1] package so that it will build and doesn't get dropped from e.g. Leap 15.2. The basic problem is that a test (or possibly multiple tests) started failing with the latest version of python-transaction. This problem is fixed upstream but there hasn't been a new version of ZODB released with the fix in it.

So I'm using a git revision as the source for the package, but this raises the question of what to do with the version number of the package. Reading some documentation[2], it would appear I should use a version like "5.5.1+git56", but this causes RPM to not find the egg-info directory in %files because the version specified in setup.py is "5.6.0.dev0".

So should I a) use version 5.5.1+git56, change the %files section so it picks up the egg-info directory or b) use version 5.6.0.dev0, but then when 5.6.0 is released upstream wouldn't RPM think that 5.6.0.dev0 is still the newer version? c) do something else.

Unless upstream has specifically released 5.6.dev0, I would go with 5.5.1+git%{short_commit}

Commits are unordered, are not they? You need something monotonically increasing to make sure next release actually has high version. Something like git-describe output which nicely piggy-backs on the latest release and is always lower version than next release.

Right, in case you want to update between commits before the next release and have a clean upgrade path, then you're probably better of to use the git commit date in the version (e.g. 5.5.1+git20200504-%{short_commit}, although I'm not sure if including the commit even makes sense).

You need to include the commit hash in the version to make it _unique_. Ordering is already happening with the `.git20200504` part (yes, I put a period there on purpose: everything that isn't a ~ or ^ is effectively a period). -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Mai 04 2020, Andrei Borzenkov wrote:

Commits are unordered, are not they? You need something monotonically increasing to make sure next release actually has high version.

You can get a monotonically increasing version with git describe. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org