June 2025 - Arch-dev-public - lists.archlinux.org

RFC Final Comment Period: Establish default build flags for Fortran
by Jakub Klinkovský 12 Jun '25

12 Jun '25

An RFC has now entered Final Comment Period. In 14 days, discussion will end and the proposal will either be accepted, rejected or withdrawn: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/54 Please visit the above link for discussion. Summary: This RFC establishes default build flags (`FFLAGS`, `FCFLAGS`, `DEBUG_FFLAGS`) for compiling Fortran code in Arch Linux packages, aligning them with the security hardening standards defined for C.

1 0

Adopting similar packages in extra
by Quentin Michaud 10 Jun '25

10 Jun '25

Hi all, I am interested in packaging vscodium [1] into extra but am worried that it would be seen as a duplicate of the code [2] package. This situation is unclear and not explicitly mentioned in the wiki [3]. I asked the question on Matrix/IRC and this stirred a larger debate, so artafinde suggested me to post the question here in order to have a record of the discussion and potential decisions. The (more generic) questions are the following: under which criteria do we want to accept multiple "similar" packages in official repos or replace one by another? Do we want to fix (or already have) rules or guidelines for these situations or do we want to proceed on a case-by-case basis? "similar" packages can mean different things, I see several categories: - Hard fork of a project but projects are very close / are trying to stay compatible. Examples : redis (AUR) / valkey (extra), terraform (extra) / opentofu (extra) - Soft fork of a project aiming at adding / removing functionalities using patches. Examples : vscode (extra) / vscodium (AUR), firefox (extra) / librewolf (AUR) and other Firefox forks - Rewrite of a project but aiming to achieve the exact same goals / drop-in replacement : Examples: sudo (core) / sudo-rs (extra), coreutils (core) / uutils (extra). This category is tricky because the definition of "exact same goals" is unclear, but I exclude software that implement common standards but that are vastly different in practice, such as docker / podman or openssh / dropbear. This is more relevant to the "replace one by another" part, as Ubuntu did recently with sudo [4]. As for the criteria on which to base these decisions, they are many but the most important ones that I was able to think of are: - licensing changes - user impact - compatibility / conflicts between forks / flavors of the same software I hope thinking and discussing about this will help us to set guidelines on how to handle such situations in the future and document it in the wiki. Your thoughts are welcome :) Cheers, Quentin Michaud / mh4ckt3mh4ckt1c4s [1]: https://vscodium.com/ [2]: https://archlinux.org/packages/extra/x86_64/code/ [3]: https://wiki.archlinux.org/title/Package_Maintainer_guidelines#Rules_for_pa… [4]: https://discourse.ubuntu.com/t/adopting-sudo-rs-by-default-in-ubuntu-25-10/…

5 5

Adopting similar packages in extra
by Quentin MICHAUD 10 Jun '25

10 Jun '25

1 0