On Sun, Mar 28, 2021 at 6:17 PM Artur Frenszek-Iwicki <suve@xxxxxxxxxxxxxxxxx> wrote: > > I'm looking to package some GTK themes. Those themes come in several colour > variants. The author decided on a workflow where, instead of keeping variants > alongside each other in the tree, each variant has its own git branch. > > When working with git snapshots, the packaging guidelines [1] say to put > the snapshot data in the Release: field. This is simple enough when working > with a single "main" source, but what when there's multiple sources? > > A solution could be to put each colour variant into a subpackage, > and make the "main" package a file-less package that just Requires: > all the colour variants. This way, each subpackage can have a different > Release: tag. However, doing this messes with rpmdev-bumpspec, which > gets confused and slaps ".1" at the end of each subpackage's Release: tag, > which in turn makes the Requires: unsatisfiable. AFAIK, having different "Release" tags for subpackages just is not supported well (or at all). There are two examples of how to work around this issue: - The ruby package bundles a bunch of gems in addition to the Ruby interpreter, and while some of the gem subpackages have different versions, there's only *one* Release tag in the whole package, and it never gets reset to 0 so the upgrade path for all subpackages works out fine. - The rust package ships the rust compiler and some tools (cargo, rustfmt, rls), and they have different "upstream" versions, but since they are never exposed to the user, these are ignored in Fedora, and just inherit the main version of the package, i.e. the version of the Rust compiler itself. Maybe you could do something different, i.e. use the %baserelease macro, which should help with rpmdev-bumpspec, at least. But it will still give you the same Release tag for each subpackage. Fabio _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
