Dne 04. 02. 21 v 20:19 Fabio Valentini napsal(a):
On Thu, Feb 4, 2021 at 7:24 PM Artur Frenszek-Iwicki <s...@fedoraproject.org> wrote:The Lazarus package currently builds three RPMs: "lazarus", which contains the IDE, and the "qt5pas" library, along with "qt5pas-devel". qt5pas is, technically, a separate project with its own versioning - but since its distributed alongside Lazarus, and Lazarus depends on it, it made sense to build them from one SRPM.In the spec, I specify a different Version: for qt5pas. This isn't a problem per-se, but means that if I upgrade Lazarus (so Version goes up and Release goes back to 1), I get a lower NVR for qt5pas. So I made a macro which gets calculated based on Lazarus's NVR, so it won't go down, and used it as the Release:. So now I have: - in qt5pas: "Release = %{qt5pas-release}" - in lazarus: "Requires: qt5pas = %{qt5pas-version}-%{qt5pas-release}" Now, the problem is: whenever a Mass Rebuild occurs, the releng scripts see the "Release = %{qt5pas-release}" bit and just slap ".1" at the end, which in turn causes the "Requires: qt5pas = %{qt5pas-version}-%{qt5pas-release}" bit to be unsatisfiable. While I could, obviously, just make a commit stripping the ".1" and rebuild the package, this approach is wasteful in regards to both my time and koji processing power, and unfriendly towards automation (as it means a mass rebuild will always produce broken packages). So I'm now wondering what would be the best approach. - Move qt5pas to a separate dist-git repo: Would solve the problem above, but make syncing the packages harder. - Drop the separate version for qt5pas and just use Lazarus's version (would need an Epoch bump, probably). This would make the package's version not match what is shipped. Any other approach I could adopt?The approach in lazarus sounds error-prone, and it looks like rpmdev-bumpspec does not recognise what you're using and just slaps a ".1" at the end, which is wrong in your case. I am aware of at least three (?) other "noteworthy" packages that have to deal with this (or at least, had to do something like this in the past): - ruby (with the gems that are bundled with the interpreter), - perl (with the modules that are bundled with the interpreter), and - rust (with tools like cargo that are bundled with the compiler) Some handle situations like these by setting Version for each subpackaged component separately and only ever incrementing Release and never resetting it to 0.
I think that Perl does not reset the release at all, Ruby has not reset the Release for quite some time, because it would require all the packages to have bumped version and that did not happened for quite some time.
Anyway, `rpmdev-bumspec` is clever enough to bump also some macros used in `Release` tag, e.g. in Ruby, there is `%global release 145` [1], which is correctly bumped.
Vít[1] https://src.fedoraproject.org/rpms/ruby/blob/35f28c9a6800eaf1d557b74e2f60d13e99cd2268/f/ruby.spec#_25
Rust handles this by just not setting the Version of cargo to its "real" version, but have it inherit the version from the Rust compiler instead. The "cleanest" way to deal with this would probably be to package them in separate "source" packages (even if built from the same upstream tarball), but if that would not work, look at how other packages handle this. :) Fabio _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
