portable APT? [LWN.net]

portable APT?

Posted Nov 24, 2025 16:42 UTC (Mon) by atai (subscriber, #10977)
Parent article: APT Rust requirement raises questions

is it possible to fork APT so these Rust components can be filled in with C/C++ implementation so portable APT can be in feature/functionality parity with the APT using Rust so these ports continue

to post comments

portable APT?

Posted Nov 24, 2025 16:53 UTC (Mon) by epa (subscriber, #39769) [Link] (5 responses)

How about a Rust to C converter? I vaguely expected that would exist somewhere. It wouldn't run the borrow checker or most of Rust's other compile time checks, but that doesn't matter, as long as the code previously built with a full Rust compiler. And it could generate code that always runs singlethreaded.

portable APT?

Posted Nov 24, 2025 17:14 UTC (Mon) by ojeda (subscriber, #143370) [Link]

For that, one may write a new backend for an existing Rust compiler. That way, the borrow checker and every other compile-time check still applies.

`rustc_codegen_clr` has such a mode, and there was also another start on a new C backend for `rustc`. Neither is "production ready", but it is a nice approach, and in fact it is not uncommon for languages to design their compilers that way.

portable APT?

Posted Nov 25, 2025 20:16 UTC (Tue) by hsivonen (subscriber, #91034) [Link] (1 responses)

Rust can target wasm and there’s wasm2c, which works well enough that RLBox is real and is used in Firefox with wasm coming from clang.

I don’t know about the level of effort requires to get the pile of C to expose the same interface as the Rust input is exposing as FFI.

portable APT?

Posted Nov 26, 2025 10:00 UTC (Wed) by moltonel (subscriber, #45207) [Link]

At that stage, you might as well compile to WASM, and run that binary using a wasm runtime on the platforms that lack Rust ?

portable APT?

Posted Nov 27, 2025 14:29 UTC (Thu) by slanterns (guest, #173849) [Link]

https://github.com/thepowersgang/mrustc

portable APT?

Posted Nov 27, 2025 23:52 UTC (Thu) by jmalcolm (subscriber, #8876) [Link]

There is a "Rust to C converter", or rather a Rust compiler that emits C (mrustc). More importantly, there are two different projects to bring Rust to GCC (gccrs and rustc_codegen_gcc).

If you can compile Rust to any architecture that supports GCC, you certainly have enough portability for APT.

Rust is already portable to the Debian architectures that people actually use. The ones that it does not support are not up-to-date anyway so shipping with an older version of APT would not be the end of the world.

As above though, there is no reason you cannot compile APT, even with Rust in it, for any of these platforms.

portable APT?

Posted Nov 24, 2025 16:53 UTC (Mon) by jmm (subscriber, #34596) [Link] (4 responses)

There's no strict dependency on apt in Debian, the whole discussion was totally blown out of proportion in the first place.
The ports w/o a Rust toolchain could still use cupt, which is written in C++.

portable APT?

Posted Nov 26, 2025 14:01 UTC (Wed) by ATLief (subscriber, #166135) [Link] (3 responses)

The apt package is marked as "Essential: yes" and "Priority: required", so anything officially supported would need to include it. I guess those designations could be removed, but their intention is probably to ensure that packages can be installed on any system. I think having multiple lowest common denominators (like apt on most systems and cupt on others) would defeat the purpose of marking them as such.

portable APT?

Posted Nov 26, 2025 16:35 UTC (Wed) by smcv (subscriber, #53363) [Link] (2 responses)

apt specifically isn't Essential, but it has a special case to treat itself as pseudo-Essential while making dependency calculations, to make sure you can't accidentally use apt to uninstall apt and then have no way to reinstall it. Non-apt package managers can uninstall it. (Try it in a minimal Debian container: "apt remove apt" fails unless you add some --force options, but "dpkg --remove apt" works fine, and presumably cupt would also allow removing it.)

Priority has very little practical effect, and Priority: required is mostly about ensuring that debootstrap and similar minimal-system bootstrap tools will install it, so that you have a route to install additional packages.

portable APT?

Posted Nov 26, 2025 17:01 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

Or you use the gentoo approach with virtual packages - something like "Pid1 is essential, can be satisfied by SysV, systemd, OpenRC, yada yada".

So you can't uninstall the only one available from the list - if two are installed there's no problem uninstalling either.

Cheers,
Wol

Debian virtual packages

Posted Nov 27, 2025 16:59 UTC (Thu) by timon (subscriber, #152974) [Link]

Debian does have virtual packages [1], e. g. “xserver” [2]; those you cannot install but they are provided by other packages. Debian also has metapackages [3], e. g. “init” [4] corresponding to your Gentoo example; those you can actually install, and they will then pull in relevant dependencies providing the actual functionality. The “apt” package [5] however doesn’t provide any relevant virtual package name.

[1]: https://packages.debian.org/stable/virtual/
[2]: https://packages.debian.org/stable/xserver
[3]: https://packages.debian.org/stable/metapackages/
[4]: https://packages.debian.org/stable/init
[5]: https://packages.debian.org/stable/apt

portable APT?

Posted Nov 24, 2025 16:56 UTC (Mon) by farnz (subscriber, #17727) [Link]

The question, as always, would be who's going to do the forking and keep up with upstream?

The other route is to contribute to things like gccrs or rust_codegen_gcc, so that Rust is available on these ports, too. This has the slight advantage that, once you have Rust support, any other packages in Debian that need Rust become buildable for that port.