(dropping the ports as my reply doesn't really concern them. Even if by some miracle src:apt won't include Rust itself, it already depends on things which are currently rust-only and that its more likely to increase than to decrease over time ~ and not just in apt ~ which ironically is facilitated by apt as its not a language-specific package manager and hence isn't locking you into a single language ecosystem for your dependencies like the current hot stuff would) Am Fri, Oct 31, 2025 at 09:48:46PM +0100, schrieb Julian Andres Klode: > In particular, our code to parse .deb, .ar, .tar, and the As your goal claims to be less bugs, I would welcome to remove them all by dropping this code from src:apt entirely. I think we can agree that this has the least bugs & is the easiest to maintain long term. We "need" it in two places: - apt-ftparchive, an aging tool, which as far as I know sees its only serious usage by your employer in the form of Launchpad, right? Of course, our tests (yes, we have them, even if you make it sound differently) make heavy use of it, too, but with serious I mainly mean the BDB part. Even if we assume we have to keep it forever, it would probably help getting it out of src:apt as it would mean it could implement e.g. new ways of signing repositories and generate them in newer versions a repository admin could adopt more easily and safely than upgrading all of apt just to generate new style repos. Implementation language wouldn't be a concern here as nobody requires a port to be entirely self-sufficient – beside, e.g. dak is python. I also have to note that I can't remember the last memory bug here, nor that I would consider it a big problem as it is kinda assumed that the deb/tar/ar we parse here is trusted data. If not, memory bugs are kind of the least concern here… (given Launchpad, I suppose you are required to see that differently) - apt-extracttemplates, a tool which was never supposed to be in src:apt to begin with, but nothing is as permanent as a temporary solution. Not that I can remember any bug with it ~ nor any real changes in the last two decades. As its a tool running as root on trusted data to execute shell scripts from that data with root rights security seems a hard sell on this one, too, through. An old and/or newly bootstrapped port also couldn't care less about the benefit it provides in the grand scheme of things, so nobody would really question the implementation language choice as a bonus. None of it is a critical path. Much less a serious security effecting one that would benefit from "memory safety". These would in fact benefit more from reusing existing code, like from dpkg. And how language and testing compute into Rust I don't quite follow. You can certainly do unit tests in C++, we do. The main problem is that someone has to write those tests. Like docs. Your new solver e.g. has none (apart from our preexisting integration tests). You don't seriously claim that is because of C++ ? If you don't like GoogleTest, which is what we currently have, I could suggest doctest (as I did in previous installments). Plenty other frameworks exist with similar or different styles. > HTTP signature verification code would strongly benefit > from memory safe languages and a stronger approach to > unit testing. Maybe we should split the transports out, too. Systems that don't need the http transport are probably unicorns that have no serious problem installing it anyhow, but this, too, could benefit from being released and updated independently from apt itself – I want to advocate less on this part, but the fact remains that this is not our memory issues covered path either (as, honestly, memory issues aren't really a thing in apt… or can you name the last crash that was the fault of the language and not of the implementor in any language like #1119056). For those not knowing, the transports are independent binaries that are executed by libapt and communicate with a textual protocol. Splitting them out of src:apt is trivial. As is writing them in any language you like. In theory we could even have different implementations, like our "old" currently existing custom HTTP1.1 implementation with all the historically grown features (aka baggage) and some which go e.g. with external libraries to higher HTTP-version spheres and/or are implemented in Rust (perl, python and brainfuck for all I care). Now, of course, we have other code paths like the deb822 parsers that are certainly hot paths and while not mentioned in this mail, you have certainly thought about reimplementing as well. For those, I can of course not offer to finally go the "split it out" path, but like Russ was explaining in his mail, a serious analyse of the benefits should be made (that he assumed was made) and I don't think a simple platitude like "its a memory safe language" is cutting it. > It's important for the project as whole to be able to > move forward and rely on modern tools and technologies > and not be held back by trying to shoehorn modern software > on retro computing devices. (We have wildly conflicting communication styles, so I have long since stopped commenting on that.) Personally, I have to question if introducing another language into an already complex piece of software that evidently nobody¹ wants to work on is a good move. I mean, yeah, sure, its popular and stuff, but so is Python, I heard, and yet I don't see a flurry of activity around python-apt (or any other language binding for that matter). Maybe, just maybe, it isn't about the implementation language. Best regards David Kalnischkies ¹ As I am currently the top-ranking nobody in contributions to src:apt according to git shortlog, this slight exaggeration can hopefully be forgiven. After all, after 16y I am technically still the newest member of the apt team and should henceforth benefit from newbie protection. P.S.: Given apt is kinda the anti thesis of bundling and static linkage you could argue that apt itself is a retro computing thing that should not stand in the way of the modern tools and technologies that have no care in the world for legacy concepts like shared libraries, distribution-specific package formats and associated manager(s). All those Debian contributors shoehorning modern software into packages for retro computing technology like apt and dpkg… (I am joking……… or am I?)
Attachment:
signature.asc
Description: PGP signature