Hi Jason,
Jason Craig
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}
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