Adopting similar packages in extra
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_pac... [4]: https://discourse.ubuntu.com/t/adopting-sudo-rs-by-default-in-ubuntu-25-10/6...
In data lunedì 9 giugno 2025 22:55:56 Ora legale dell’Europa centrale, Quentin Michaud ha scritto:
Hi all,
Hi
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.
From what I understand code and VSCodium are basically the same thing, or at the very least they aim to produce almost the same result and it wouldn't make sense to have them both in [extra]. From the VSCodium homepage: "If you want to build from source yourself, head over to Microsoft’s vscode repo and follow their instructions". That is what the "code" package does. VSCodium is a prebuilt package, and when you then go and build it from source you are just building code (Github project description: "binary releases of VS Code without MS branding/telemetry/licensing") That's at least if the project description is accurate. I am not aware if there are more substantial code changes between the 2 repos. That being said I really don't like to maintain code, so if you want to adopt it and rename it you have my blessing and I would very much like to abandon it. -- Massimiliano Torromeo
Jun 9, 2025 23:52:06 Massimiliano Torromeo <mtorromeo@archlinux.org>:
That's at least if the project description is accurate. I am not aware if there are more substantial code changes between the 2 repos.
That being said I really don't like to maintain code, so if you want to adopt it and rename it you have my blessing and I would very much like to abandon it.
I think we shouldn't mix both topics here. One is about guidelines of bringing in the same software "but with patches". The other is that you'd like to not maintain code anymore. The latter is fair, but we should call out for help with the official code package instead of using the opportunity and potentially forcing some undesired opinionated thing onto all code users. Vscodium does have some weird patches in them, and I personally don't trust the judgment done here. It surely serves a purpose and surely love and energy is put into it which a lot of users may be happy about (especially the pre built vscodium variants for simple download). But it also does things like pulls in npm packages with pre-built binary openssl as a shortcut. It also deactivated extension signatures to work around an issue with one particular area they had. And they are also not just removing telemetry, but functionality they are opinionated about. My two cents: please let's not force vscodium into the mouth of all regular code users, but see who is eager to help out maintain code. Thanks and cheers, Levente
In data lunedì 9 giugno 2025 22:55:56 Ora legale dell’Europa centrale, Quentin Michaud ha scritto:
Hi all, Hi
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. From what I understand code and VSCodium are basically the same thing, or at the very least they aim to produce almost the same result and it wouldn't make sense to have them both in [extra].
From the VSCodium homepage: "If you want to build from source yourself, head over to Microsoft’s vscode repo and follow their instructions". That is what the "code" package does.
VSCodium is a prebuilt package, and when you then go and build it from source you are just building code (Github project description: "binary releases of VS Code without MS branding/telemetry/licensing")
That's at least if the project description is accurate. I am not aware if there are more substantial code changes between the 2 repos. There's some modifications in vscodium on top of just building vscode, that may not be aligned with what most users are expecting from the code package. That's why replacing code by vscodium is not a solution but a case can be argued in allowing vscodium in extra too.
That being said I really don't like to maintain code, so if you want to adopt it and rename it you have my blessing and I would very much like to abandon it.
As said above I don't intend to replace code by vscodium as there are some differences that may cause trouble for current code users. But either vscodium is allowed in extra and I maintain it in extra (should be very similar to the code package), either it is not and then I'll probably make a switch to using code. In both cases I'd be happy to help you in packaging code or take over the maintenance if you want to abandon it. I'll add myself as co-maintainer.
On 6/9/25 10:55 PM, Quentin Michaud wrote:
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?
I think this should be up to the packager maintainer's discretion, and if the software is relevant enough (but that's difficult to quantify).
- 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].
I think all projects mentioned would be suitable for [extra] if somebody is willing to take the responsibility of maintaining them (note however browsers need a lot of special attention, due to the urgency of security updates, and upstream should have a good track-record in doing so, i.e. "no toy browsers"). We also have libtorrent and libtorrent-rasterbar for example, somebody felt like we should have both and nobody took issue. What wouldn't qualify, in my opinion, would be "it's the exact same software but with one Github issue patched that upstream is unresponsive about". Also "the less relevant the software and it's fork, the better the reason needs to be". Furthermore, I think Arch Linux is mostly providing "unopinionated building blocks"[1], so if there's two relevant solutions both of them would be available and it's up to me to decide which one of them I want for my computer. For uutils that happens to be difficult, I've filed an issue upstream in the hopes of moving this forward and one could opt-in through $PATH: https://github.com/uutils/coreutils/issues/8029 cheers, kpcyrd [1]: "a documentation project of the opensource ecosystem, about what the source code is and how to compile it, that also happens to provide pre-compiled binaries", if you will
participants (5)
-
Christian Rebischke
-
kpcyrd
-
Levente Polyak
-
Massimiliano Torromeo
-
Quentin Michaud