Debian verplicht vanaf volgend jaar Rust-ondersteuning in packagemanager apt

De packagemanager apt krijgt op Debian ondersteuning voor Rust en vanaf volgend jaar wordt die ondersteuning ook verplicht voor alle ports en forks. Een van de hoofdontwikkelaars van Debian wil ondersteuning voor de memory safe toolchain vanaf mei verplichten.

Debian-ontwikkelaar Julian Andres Klode schrijft dat in een mailinglijst. Na mei 2026 worden Rust-dependency's en -code verplicht in apt op Debian. Dat begint volgens hem bij de compiler en bij Sequoia, de Rust-implementatie van OpenPGP. Vanaf mei volgend jaar wordt het verplicht voor alle forks en ports van Debian om Rust te ondersteunen. Dat betekent dat Debian-ontwikkelaars binnen een klein half jaar Rust-ondersteuning moeten toevoegen aan de packagemanager.

Klode merkt op dat de meeste grote Debian-ports in ieder geval al algemene Rust-ondersteuning hebben, al hebben kleine ports zoals DEC Alpha of Hewlett-Packard Precision Architecture (HPPA) dat nog niet. Voor zulke distro's kan het lastig worden goede ondersteuning toe te voegen.

Volgens ontwikkelaar Klode zouden parsers voor bijvoorbeeld .deb- of .tar-bestanden baat hebben bij ondersteuning voor talen die 'memorysafe' zijn. Rust wordt over het algemeen gezien als programmeertaal die veel geheugenbugs kan voorkomen. Veel ontwikkelaars spreken zich in de mailinglijst ook uit tegen de ontwikkeling. Ze vinden de deadline van een kleine zeven maanden voor implementatie erg kort. Klode zegt dat ports die de deadline niet halen op termijn worden uitgefaseerd als officiële Debian-ports.

Reacties (15)

[BezurK]

Wat wordt hier nou eigenlijk gezegd? Wordt heel APT herschreven in Rust? Moeten alle packages die gepubliceerd worden in de Debian repo geschreven worden in Rust? Moeten packages kunnen compilen met de toolchain van Rust? (kan dat uberhaupt?! lijkt me niet)

Ik begrijp niet zo goed wat hij nu precies bedoeld.

I plan to introduce hard Rust dependencies and Rust code into
APT, no earlier than May 2026. This extends at first to the
Rust compiler and standard library, and the Sequoia ecosystem.

Hier lees ik dat hij voor mei Rust code en dependencies wil gaan toevoegen aan APT. Dat klinkt als een solide beslissing. Er wordt op het moment wel meer FOSS deeltje voor deeltje geport naar Rust door stapje voor stapje Rust code te introduceren.

In particular, our code to parse .deb, .ar, .tar, and the
HTTP signature verification code would strongly benefit
from memory safe languages and a stronger approach to
unit testing.

Makes sense.

If you maintain a port without a working Rust toolchain,
please ensure it has one within the next 6 months, or
sunset the port.

Hier gaat het voor mij dus verwarrend worden. Voor zover ik weet is een "port" niets anders dan een package die een core deel van de Debian distro vormt. Een applicatie(tje) dus. In welk opzicht moeten die dan een "working Rust toolchain" hebben ... ?

Wie legt het uit?

[markiemannie]

Met een port wordt geen applicatie bedoelt maar een architectuur. Debian heeft een dozijn officiele en onofficiele ports, niet alleen x86 maar denk aan arm, IBM Mainframes maar ook wat obscuurdere dingen zoals MIPS, PA-RISC en ga maar door. Al deze ports gaan dus een werkende rust toolchain vereisen.

[BezurK]

Ah, dan valt het kwartje! Doordat het over APT ging dacht ik direct aan ports = packages en daar gaat de beredenering dan mank natuurlijk. Niet om per sé mijn gelijk te halen maar volgens mij werden heel veel core GNU tools ook ports genoemd omdat ze "overgenomen" werden uit de Unix wereld. Maar goed, totaal logisch dat de ports waar over gepraat wordt in deze context gewoon architectuur-ports zijn, haha. Thanks :)

[jasper580]

Rust code wordt gecompileerd naar 0'en en 1'en die de computer daadwerkelijk kan uitvoeren. Dat compileren gebeurd door de rust toolchain. Niet elke computer interpreteert die 0'en en 1'en op dezelfde manier: computers verstaan meestal x86_64, terwijl je telefoon arm verstaat.

Wat hier gezegd wordt is dat, als je een port van debian bijhoudt, je ervoor moet zorgen dat rust kan compilen naar jouw variant. Voor de meeste computers is dit al gebeurd, maar voor minder gebruikte architecturen kan het zo zijn dat deze nog niet opgenomen is in Rust. De auteur zegt in de laatste quote in feite: "als jouw architectuur nog niet ondersteund wordt dan wordt APT compileren lastig in de toekomst, zorg dat of 1) rust jouw architectuur support of 2) stop met je port"

[Reactie gewijzigd door jasper580 op 3 november 2025 16:07]

[GertMenkel]

Op zich hoeft een port natuurlijk niet de officiële Rust-toolchain te ondersteunen. Aangezien de enige ports die hier last van hebben zwaar obscuur zijn of geheime/proprietary ports zijn, kan ik me voorstellen dat bedrijven die hun eigen specialistische distro bijhouden eerder de focus zullen leggen om gcc's Rust frontend ondersteuning te geven voor de code die in apt terechtkomt.

Ook kunnen ze een "goed genoege" LLVM-backend optuigen. Voor officiële ondersteuning moet je dingen doen als "ondersteuning garanderen" waar bedrijven als Expressif in het verleden door zijn afgehaakt, maar je kunt ook je eigen fork maken die net goed genoeg is om apt te compileren.

Het mooiste zou zijn als deze obscure platformen ook LLVM/mainstream Rust-ondersteuning krijgen, maar het is niet de enige manier om dat voor elkaar te krijgen.

[SPee]

Van wat ik hieruit opmaak, is dat ze Rust gaan gebruiken in APT. Dus dat eenieder die APT bouwt vanaf source ervoor moet zorgen dat je ook Rust kan gebruiken tijdens het compileren.

Dus dat geldt voor iedereen die Debian 'port' naar een bepaalde architectuur (x86, arm, etc). En dus ook voor iedereen die een Debian afgeleide maakt en dat vanaf de sources doet (bijvoorbeeld Ubuntu). Als jouw toolset om die port te maken geen Rust ondersteund, dan kun je vanaf dan APT niet meer compileren, omdat een deel ervan in Rust is geschreven. Je zou nog wel een soort Frankenstein distributie kunnen maken, waarbij je een oude APT versie gebruikt, maar er zal steeds meer verschil in komen met steeds grotere kans op problemen en de weigering om jouw specifieke bugs op te lossen in hun code.

Dat langzaam overstappen naar Rust is een beetje mixed. Ja, hiermee zal bepaalde memory issues voorkomen worden. Maar het gaat hier veelal om code die meer dan 20 jaar langzaam geëvalueerd is en die problemen er al uitgehaald zijn. En die robuuste en bekende tools vervangen gaat niet zonder problemen. En ook fouten zoals een verkeerde waarde parsen lost Rust niet op. Enkel dat het geen bufferoverflow of -underflow oplevert. Dus het is nog maar zeer de vraag of het meerwaarde oplevert (in deze context).

[Knallmeister]

Lijkt erop dat ze bij Debian de ontwikkelingen van Ubuntu deels gaan overnemen.

YouTube: Ubuntu Linux is Getting Rusty..

Kijk ook naar de Sources

[SPee]

Die overgang gaat niet zonder problemen:

Bug in Rust-Based Uutils Broke Ubuntu 25.10 Automatic Update
Rust Coreutils Are Performing Worse Than GNU

En dan zijn er nog meningsverschillen over de gebruikte licentie; MIT in plaats van GPL.

[Knallmeister]

En dan zijn er nog meningsverschillen over de gebruikte licentie; MIT in plaats van GPL.

Debian heeft zich zeer lang als een van de meest puristische Linux distro's opgesteld door zich expliciet GNU in de naam te vermelden. Zouden ze het aandurven om in de nabije toekomst MIT in de naam op te nemen? Lijkt me niet.

[Ebbez]

GNU is een collectie applicaties "bruikbaar als besturingssysteem", en MIT is een licentie. Een betere vergelijking zou Debian uutils/Linux zijn.

[blorf]

Ik ben een beetje bang dat de PC-industrie via financiering gaat proberen de controle over de machine voor de consument te verkleinen. Nu is het optioneel, maar memory-safe kan er ook op neerkomen dat instructies ontoegankelijk worden gemaakt voor gebruikers die geen kernel van een "whitelist" draaien, wat dan als zwakke beveiliging wordt affespiegeld. In het ergste geval 1 met verplichte binary-data, standaard gemaakt door nVidia en Steam of Microsoft.

[AnonymousGerbil]

Tsjah, van canonical was, dacht ik, toch wel bekend dat die vernieuwingen doorvoert die soms nog niet echt van de kwaliteit zijn die men bij een grote distributie mag verwachten. Zelfs bij lts uitgaves.

Iets waarvan debian niet beschuldigd kan worden.

[Lethalis]

Tsja, als gebruiker merk je daar waarschijnlijk weinig van... als het blijft werken.

Hoogstens dat ik als programmeur denk dat ik misschien toch meer met Rust moet doen.

[beerse]

Een mooi overzicht van deze oudere architecturen ten opzichte van de huidige ontwikkelingen. Het doet mij beseffen dat deze architecturen 30 jaar geleden nog wel een actuele waarde hadden maar ook al een gewis einde. De Intel Itanium architectuur was voor een aantal van deze wel gezien als een opvolger.

Voor mij zelf is het al weer 20 jaar geleden dat ik op een hp-pa-risc systeem een gentoo installatie heb uitgevoerd, om te kijken of dat kan. Natuurlijk is het leuk "omdat het kan" en is het de sport om het in gang te houden. Maar ondertussen vraag ik mij wel af waar deze systemen nog voor gebruikt worden, anders dan 'omdat het kan'. Mijn hp-pa-risc systemen zijn jaren geleden al afgevoerd.