Closed praiskup closed 2 days ago
FWIW, tito project itself has the problem now:
$ sudo dnf copr enable @rpm-software-management/tito
$ sudo dnf update tito
...nothing happens...
the version in Copr is 0.6.24-1.fc39 compared to system default 0.6.24-2.fc39
Thinking out loud ... so, can we simply automatize the same thing that #480 did? When using --test
, tito would add the .post1
suffix for the version? The suffix could be optional (opt-out probably) and configurable.
For me, this is hard to predict. Can we simply try that? Seems like a nice experiment.
Just tried to chain build the client Copr packages from git-head:
mock --chain \
/tmp/tito/python-copr-1.132-1.git.75.658230d.fc41.src.rpm \
/tmp/tito/copr-cli-1.112-1.git.78.658230d.fc41.src.rpm
But for the copr-cli
package it always installs:
python3-copr noarch 1.132-3.fc41 fedora 241.8 KiB
The typical problem I have:
Package
Foo
withVersion: 1.1
andRelease: 1
is tagged to upstream git, and released (to Fedora)Then
tito build --test ...
works fine because the generated release looks like1.git.3548.f7f3934
. This is fine, because:IOW, the package with
--test
has a higher NVR than the one in Fedora.After some time, the Fedora package gets an asynchronous update by Fedora community, bumping
Release: 2
(rebuild for GCC bump, e.g.)The
--test
package still provides the same NVR with1.1-1.git.3548.f7f3934
which is though:If the
--test
package is e.g. built n Copr, or locally, it doesn't easily update the one installed on the system which complicates testing.I'm not saying now how to resolve this, or whether we should do it by default. But it would be nice to have a way to provide a higher NVR than the one in Fedora somehow. E.g. by bumping the Version? Bumping Release to
666
? I don't know.