https://bugzilla.redhat.com/show_bug.cgi?id=2262452 Dridi Boukelmoune <dridi.boukelmoune@xxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dridi.boukelmoune@xxxxxxxxx --- Comment #3 from Dridi Boukelmoune <dridi.boukelmoune@xxxxxxxxx> --- I'd like to share more feedback regarding the packaging as it stands today, and it will follow the same line as the previous one. I have recently needed to reinstall golang for work and I had forgotten how the package was structured on Fedora, and it reminded me of this ticket. It looks like a lot of inspiration was drawn from the golang packaging in Fedora to put together this hare packaging. I've always found this packaging jarring, but there must be good reasons for things to be put together as they were, but I can't help wonder about over-engineering: $ rpm -qR golang | grep go- go-filesystem $ rpm -ql go-filesystem /usr/share/gocode /usr/share/gocode/src $ rpm -ql golang | grep /usr/share/gocode /usr/share/gocode /usr/share/gocode/src /usr/share/gocode/src/bitbucket.org /usr/share/gocode/src/code.google.com /usr/share/gocode/src/code.google.com/p /usr/share/gocode/src/github.com /usr/share/gocode/src/golang.org /usr/share/gocode/src/golang.org/x What is the purpose of the go-filesystem package? It doesn't appear to have scriptlets. Back to hare, I only had a quick skim through the RPM spec, but I found the following packages: hare hare-bin hare-src hare-filesystem hare-cross-compile-gnu hare-cross-compile-llvm I feel that this really is a lot of packages for a project that aims at overall simplicity. Like I said in a previous message, we really have two things in the tool chain. The GPL-3.0-only hare and haredoc programs, and the MPL-2.0 standard library: hare hare-stdlib We should eventually provide RPM macros for hare (standard and) third-party libraries, but if the macros in question rely on the hare tooling to for example list dependencies, then we may get away with putting them in the main hare package. Packages can always be split later if they come short of use cases that may appear in the future. Regarding cross compilation, the hare tool chain will embed a default configuration, so we pick one and create the corresponding dependencies. If dependencies are too strong, we can recommend or suggest them instead. They are discoverable using the RPM command and they can even be mentioned in the package description, so users can figure out somehow that they simply need to install binutils-aarch64-linux-gnu to target aarch64. For me, the hare-cross-compile-* packages further complicate the picture instead of providing a neat and tidy abstraction. Power users will easily figure out how to tweak their cross-compilation environment anyway. Non-power-user-me managed to get there. I'm not insisting on simplicity out of nowhere. Besides my vested interest in not having a complicated setup, I picked it up from the upstream project. Some examples: https://harelang.org/blog/2022-04-25-announcing-hare/ https://drewdevault.com/talks/hare.html https://harelang.org/blog/2022-09-06-cross-builds-with-hare/ Unless there are guidelines that insist on not going with the straightforward solution, what I'm suggesting should be enough. I hope you will reconsider, start small, and expand as needed. -- 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=2262452 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202262452%23c3 -- _______________________________________________ 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
