https://bugzilla.redhat.com/show_bug.cgi?id=2154514 --- Comment #15 from Dridi Boukelmoune <dridi.boukelmoune@xxxxxxxxx> --- (In reply to Fabio Valentini from comment #11) > Side note: Dependencies like this are discouraged (SHOULD NOT): > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > #_file_and_directory_dependencies > > And they will possibly be either broken or forbidden soon: > https://pagure.io/fesco/issue/3097 Hello Fabio! Thanks for the heads up, I was aware of this policy but forgot about it. I was not aware of the incoming DNF change. My main motivation is that the time::chrono module explicitly loads this file, and I remembered something about tzdata being split for containers (https://fedoraproject.org/wiki/Changes/tzdata-minimal) and this would have made the selection of the right package transparent. It looks like tzdata-minimal is gone on my f39 laptop, I was not aware of the change being reverted. Not much time to follow changes these days... (In reply to Mike Rochefort from comment #13) > > This could simply be a Requires on tzdata. > > That's exactly what I did in my spec. This is not enough, Hare programs including the time::chrono module, even indirectly, need this file to be installed at run time. Either a dependency generator can deduce that, or a %{hare_expires} macro is offered to all packages written in Hare. The precedent I'm aware of is %{systemd_requires} for having used it on $DAYJOB. > > a hare-srpm-macros package that's part of the default buildroot > > This is another thing I'm working on on the side, however I don't think this > needs to be ready for the initial inclusion of Hare. In my spec (for my current personal usage) I didn't bother making an SRPM sub-package, but I think this should be provided one way or another from the beginning. (In reply to Maxwell G from comment #12) > As for new `%{qbe_arches}` and `%{hare_arches}` macros, those should be > added to redhat-rpm-config directly or a hare-srpm-macros package that's > part of the default buildroot (I prefer the latter) so packaged can use > `ExclusiveArch: %{hare_arches}`. That can be handled down the line. In my spec I made sure to distinguish between %{hare_build_arches} and %{hare_host_arches} as they may not always match. They currently don't. (In reply to Mike Rochefort from comment #14) > > I solved the cross-compiling configuration and dependencies with Lua macros > > I have this fixed in my unpushed spec, but not using Lua. I don't think > cross-compiling toolchains need to be installed by default or even as a > recommends, so I have an optional -cross-compile-gnu subpackage that > requires binutils and gcc for the correct non-native architectures. > > The reason for the -gnu suffix is in the even that it is possible to use the > llvm and clang utilities as a runtime override, then I'm giving it space to > have a -cross-compile-llvm subpackage without needing to do any > provides/obsoletes. > > The config itself is still dynamically generated rather than having multiple > architecture configs to select from, but it produces the correct output now. How do you do that? The makefile that produces /usr/bin/hare with its default configuration for cross compilation, so from the sound of it you'd have to ship 3 hare binaries: one for the regular package and one for each cross toolchain. Are you installing something like hare, hare-gnu and hare-llvm in %{_libdir}/hare/ and managing %{_bindir}/hare with update-alternatives? As an end user this sounds like the opposite of the complications I'd want on day 1. My 2 cents. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=2154514 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202154514%23c15 -- _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-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/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
