https://bugzilla.redhat.com/show_bug.cgi?id=2154514
--- Comment #15 from Dridi Boukelmoune <dridi.boukelmoune(a)gmail.com> ---
(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=rep...