Re: [opensuse-packaging] update package with git revision

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

...

...

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

-- Dan Čermák Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer