Laatste rituelen voor het Chromium-pakket van Gentoo

Chromium, het open-source upstream-project voor de Google Chrome-webbrowser, is de browserkeuze voor veel Linux-gebruikers. Het heeft echter ook een reputatie opgebouwd als een pakket dat moeilijk te verpakken en te bouwen is voor Linux-distributies: Chromium heeft een complex bouwsysteem, het project bundelt veel van zijn afhankelijkheden en er zijn frequente releases. Al deze factoren, samen met klachten van gebruikers, hebben ertoe geleid dat de beheerders van het Gentoo Chromium-pakket hebben besloten te stoppen met het onderhoud ervan.

Gentoo richt zich op het stেলার gebruikers hun eigen software vanuit broncode te laten bouwen met behulp van de softwarebeheer-tool Portage. Gentoo-verpakkers maken ebuild-bestanden; dit zijn tekstbestanden geschreven in een Bash-achtige syntaxis die de informatie bevatten die Portage nodig heeft om de software te bouwen. Gebruikers bouwen de pakketten vervolgens zelf met emerge, de command-line interface voor Portage. Een recente ebuild voor Chromium illustreert de complexiteit van het pakket.

Gentoo biedt via het Binhost-project ook vooraf gebouwde binaire pakketten aan voor sommige software. Het bouwen vanuit broncode geeft gebruikers echter de flexibiliteit om USE-flags te gebruiken om compile-time opties in te stellen of de configuratie van een pakket te wijzigen. Zo kan een gebruiker specificeren welke optionele bibliotheken aan een pakket worden gekoppeld, of dat de bijbehorende documentatie moet worden geïnstalleerd.

Bij Chromium specifiek kan een gebruiker de -bundled-toolchain USE-flag gebruiken (die Portage vertelt om de gebundelde toolchain niet te gebruiken) om de systeemversie van Clang te gebruiken voor het compileren van Chromium, in plaats van de gebundelde versie die door het upstream-project wordt meegeleverd. Dit is optioneel voor Gentoo-gebruikers op x86-64-systemen, maar -bundled-toolchain is vereist voor gebruikers op andere architecturen, aangezien de gebundelde toolchain van Chromium alleen wordt geleverd voor x86-64.

Het is vermeldenswaard dat Chromium momenteel niet beschikbaar is als binair pakket van Gentoo vanwege problemen met het bouwen van het pakket met propriëtaire codecs.

Laatste rituelen

Veel distributies, waaronder Arch Linux, Debian en Fedora, gebruiken de term "orphan" (wees) voor pakketten die door hun beheerder zijn verlaten; de ontwikkelaar kondigt aan dat een pakket een wees is, waarna andere contributeurs de mogelijkheid hebben om het beheer over te nemen. De terminologie van Gentoo is iets dramatischer: een pakketbeheerder kondigt "last rites" (laatste rituelen) aan voor een pakket op de gentoo-dev-announce mailinglijst om het project te laten weten dat het niet meer wordt onderhouden, en om andere ontwikkelaars de kans te geven het beheer op te eisen.

Nadat een ontwikkelaar de laatste rituelen heeft uitgeroepen, wordt de ebuild van het pakket gemaskeerd in de ebuild-repository van Gentoo om te voorkomen dat gebruikers per ongeluk een pakket installeren dat niet langer wordt onderhouden. Gebruikers die het pakket al hebben geïnstalleerd en een upgrade proberen uit te voeren, krijgen een waarschuwing dat het is gemaskeerd. Chromium-pakketbeheerder Sam James riep op 24 september de laatste rituelen uit voor het Chromium-pakket, na een langdurig gesprek in een bugrapport dat was ingediend door Roman Žilka.

Op 9 september klaagde Žilka dat de nieuwste stabiele versie van de Chromium ebuild verouderd was:

"De nieuwste stabiele www-client/chromium (en google-chrome en mogelijk anderen) is 151.0.7922.169, die 602 bekende kwetsbaarheden van alle ernst bevat. Er moeten maatregelen worden genomen door iemand die gekwalificeerd is, zodat dit niet blijft gebeuren in pakketten die zo belangrijk zijn als deze."

Hij had een ebuild voor een nieuwere versie van Chromium aan het bugrapport toegevoegd, maar merkte op dat deze niet zou werken als een gebruiker Chromium probeerde te compileren met de -bundled-toolchain USE-flag.

James antwoordde: "Chromium is verschrikkelijk om te onderhouden als bronpakket. Het is met gemak het pakket in Gentoo dat de meeste beheerders uitput." Hij stelde dat klagen over het onderhoud niet hielp en voegde eraan toe dat de beheerders de afgelopen jaren meerdere malen dicht bij de laatste rituelen voor Chromium zijn gekomen vanwege de moeilijkheid om het up-to-date te houden. Hij merkte ook op dat hij dit eerder aan Žilka had verteld en zei dat het welkom zou zijn als hij wilde helpen met het pakket.

Inderdaad had Žilka in augustus een soortgelijk bugrapport ingediend over het aantal kwetsbaarheden in de Chromium ebuild; James antwoordde toen dat het pakket altijd al moeilijk te onderhouden was, "en nu hebben ze ook Go" als afhankelijkheid toegevoegd. Voor die tijd had Žilka gereageerd op een bugrapport van Matt Jolly over Chromium-kwetsbaarheden om te klagen dat "het updateproces gerepareerd moet worden, zodat gebeurtenissen als deze niet opnieuw gebeuren in pakketten die zo kritiek zijn als deze!"

Jolly antwoordde dat de beheerders een team van vrijwilligers zijn die hun best doen, maar dat "bouwfouten, menselijke factoren ('ik heb een fout gemaakt bij het toewijzen van de bug en de automatisering heeft het niet opgepikt') en mijn eigen beperkte vrije tijd de grootste oorzaken van vertraging zijn". De beste manier om de situatie te veranderen, zo zei hij, zou zijn dat Žilka zich als vrijwilliger aanmeldde.

Trial and error

Er zijn diverse third-party repositories, genaamd overlays, die extra en alternatieve ebuilds voor Gentoo aanbieden. Op 11 september zei Nick Reale dat hij ebuilds voor een nieuwere versie van Chromium uit de Bentoo- en Fireburn-overlays had geprobeerd, maar dat hij geen van beide werkend kreeg. Een paar dagen later meldde hij succes met de ebuild van Bentoo en een specifieke set USE-flags. Er volgde een discussie tussen Reale en François Valenduc over verschillende methoden die zij konden gebruiken om een bijgewerkte versie van Chromium op Gentoo te compileren vanuit andere ebuilds.

Op 18 september merkte Valenduc op dat versie 153.0.8010.47 van Chromium uit was, en dat die versie al beschikbaar was in Arch Linux, openSUSE, SUSE en Ubuntu. "We wachten nog steeds op Gentoo, ondanks alle voorstellen die hier zijn gedaan."

James antwoordde dat geen van de beheerders nog de kans heeft gehad om naar de problemen met het Chromium-pakket te kijken. Hij zei dat de patches en ebuilds die bij het bugrapport waren ingediend "nuttig en gewaardeerd" waren, maar dat het "niet zo eenvoudig is als het gewoon pakken en committen". Gebruikers zouden klagen, zo zei hij, als de beheerders de ebuilds niet hadden getest en deze op hun systemen kapot zouden gaan.

"Het komt goed wanneer het goed komt, maar het is waarschijnlijker dat het 'last-rited' wordt als niemand geïnteresseerd is om het op de manier te behandelen zoals deze dingen gedaan moeten worden (wat verder gaat dan alleen ebuilds toevoegen)."

Valenduc zei dat hij het pakket niet kon beheren, "maar het nemen van de ebuild uit de bentoo-overlay was niet zo moeilijk [...] Het is alleen frustrerend om te zien dat er geen updates zijn in Gentoo." James antwoordde dat het feit dat de ebuild voor Valenduc werkte, niet betekende dat alle USE-flags werkten. Hij voegde eraan toe dat niemand een patch voor de Gentoo ebuild had ingediend, wat betekende dat de beheerders de wijzigingen via reverse-engineering (door ebuilds te diffen) moesten uitzoeken. "Dat alles is een niet-triviale hoeveelheid werk, en hoewel het hebben van een ebuild om mee te beginnen nuttig is, betekent het niet dat men het simpelweg kan git add && git commit && git push." Valenduc erkende dat hij niet alle mogelijke USE-flags kon testen, aangezien het compileren van Chromium op zijn laptop tussen de 15 en 16 uur duurde.

Op 24 september merkte Žilka op: "Dit is belachelijk". Een paar minuten later antwoordde James "OK dan", en riep hij de laatste rituelen uit voor het pakket.

Kan het behouden worden?

Maciej S. Szmigiero vroeg of het mogelijk zou zijn om de ebuild in de repository van Gentoo te behouden en simpelweg te verklaren dat deze op "best effort"-niveau werd onderhouden. "Het verwijderen van een buildbare/patchbare Chromium is een groot verlies voor een Gentoo-desktop." James zei dat hij niet dacht dat dat mogelijk was. Hij had al uitgelegd dat Chromium door vrijwilligers werd onderhouden, en dat die uitleg niet was geaccepteerd.

Mensen waren vrij om de ebuild in een andere repository te onderhouden, zei hij, maar dat betekende dat ze het werk zelf zouden moeten doen of zouden moeten accepteren dat iemand het volgens een lagere standaard deed. Hij wees erop dat de ebuilds van de Bentoo-overlay in de discussie waren genoemd, maar dat de creatie van die ebuilds "zwaar geautomatiseerd" leek te zijn en sommige fixes in de Gentoo-versie had gemist. "Het kopiëren van ebuilds werkt prima, totdat het niet meer werkt."

James voegde eraan toe dat iemand het Chromium-pakket nog steeds kon overnemen vóór het einde van de periode van de laatste rituelen op 24 oktober, of dat het pakket in de toekomst hersteld zou kunnen worden. Hij wilde dat echter niet zien, tenzij er een plan was voor duurzaam onderhoud. "Chromium heeft een geschiedenis van het uitputten van beheerders in Gentoo vanwege de hoge snelheid van churn upstream, hoewel sommige van de inhoud van deze bug niet bepaald helpt bij de motivatie."

Matt Whitlock vroeg zich af of de factor van burn-out bij ontwikkelaars verminderd zou kunnen worden door de meeste USE-flags voor Chromium te elimineren, of als de beheerders zouden stoppen met het ontbundelen van third-party bibliotheken.

"Wat ik in feite vraag is: kunnen we al de flexibiliteit opgeven waar we in www-client/chromium aan gewend zijn geraakt, in ruil voor een pakket dat daadwerkelijk onderhoudbaar is, maar nog steeds wordt gebouwd vanuit bronnen door een toolchain die niet wordt gedistribueerd als ondoorzichtige binaries?"

Hij voegde later toe dat een deel van het probleem was dat de upstream-projectontwikkelaars "hun builds niet testen met enige van hun zogenaamd 'optionele' functies uitgeschakeld". Dat liet de verantwoordelijkheid bij de downstream-pakketbeheerders. "In het geval van Chromium is het in stand houden van alle schakelaars (ondanks chronische verwaarlozing door upstream) een monumentale, bijna onoverkomelijke taak."

Complexiteit

Dat was een goede vraag, zei James, maar een deel van de recente complexiteit bij Chromium was de toevoeging van Rust- en Go-afhankelijkheden. De verpakkers moesten wat moeite doen om ervoor te zorgen dat de Go-build geen netwerktoegang vereiste, wat verboden is bij Gentoo ebuilds, maar dat was niet het enige probleem. Hij zei dat Google-ontwikkelaars experimentele Rust-functies lijken te blijven gebruiken die bij nieuwe releases kapot gaan. Daarnaast "is nog een probleem dat de CI van upstream om release-tarballs te produceren onbetrouwbaar is". Een van de Gentoo Chromium-beheerders had patches gestuurd om dat op te lossen, met weinig resultaat. "Het duurde eeuwen voordat ze werden gereviewd, en sindsdien is het al een paar keer opnieuw kapotgegaan. Ze leken niet te merken of te geven om het feit dat er ofwel geen tarballs werden geproduceerd, of dat ze incompleet waren."

Jolly voegde zijn eigen observaties toe over de problemen bij het onderhouden van Chromium voor Gentoo. Hij zei dat het onderhouden van Chromium meer dan zes uur per week in beslag kan nemen, en dat was alleen de compilatietijd op een snelle pc met "een absurde hoeveelheid RAM". De compilatietijd is nog langer voor 64-bit Arm-machines.

"Het is een toezegging om minstens een werkdag van je vrije tijd per week te besteden wanneer je het rebasen van patches, het cherry-picken van fixes, het itereren op ebuild ... clean compile meerekent, plus het proberen te identificeren en oplossen van nieuwe bugs, uitzoeken hoeveel je de Gentoo-policy schendt door niet meer van de browser te ontbundelen, tijd besteden aan automatisering om later tijd en fouten te besparen, enz. Er is een enorme druk om builds up-to-date te houden, zeker in een tijd van honderden wekelijkse browser-CVE's."

Hij voegde een "preventieve FAQ" toe aan zijn antwoord over de laatste rituelen voor Chromium, en wat er nodig zou zijn om het pakket te herstellen. Hij zei dat er geen onoverkomelijke technische problemen waren bij het onderhouden van Chromium, maar dat er meerdere beheerders nodig zouden zijn met een breed scala aan vaardigheden—waaronder bekendheid met C, C++, Go, JavaScript en Rust. "Er is ook een enorm aantal NIH [not invented here] Google-tools waar je vaardigheden voor zult moeten ontwikkelen die je nergens anders kunt gebruiken - beschouw dit als een waarschuwing."

Het gebruik van de toolchain van Google zou eenvoudiger zijn, maar het zou de ebuild ook beperken tot x86-64, zei hij. "We zouden arm64, ppc64 en de RISC-V overlay verliezen - beter is het om de pleister er nu in één keer af te trekken, aangezien het de situatie niet materieel verbetert." Hij voegde eraan toe dat hij bereid zou zijn om commits te reviewen en advies te geven aan iedereen die de bron-ebuild wilde onderhouden, maar hij had het gevoel dat er minstens drie mensen nodig zouden zijn. "De geschiedenis heeft aangetoon dat één beheerder niet werkt, en we hebben de releasecyclus sinds ik in 2023 met het beheer begon twee keer zien verkorten; het was toen al slecht, en nu is het erger."

De release-cadans voor Chromium is, om zachtst te zeggen, agressief. Chromium heeft meerdere kanalen, waaronder stable, beta en development. Er is ongeveer elke twee weken een nieuwe hoofdbranch van de browser via het stable-kanaal, en er wordt elke week een nieuwe versie uitgebracht.

Chromium verkrijgen

Voor nu lijkt het erop dat Gentoo-gebruikers elders moeten zoeken naar een geschikte Chromium ebuild, een andere browser moeten kiezen, of een andere distributiemethode moeten vinden om Chromium te verkrijgen. Zo kunnen Gentoo-gebruikers de Flatpak van Flathub installeren, maar dit is een niet-geverifieerd pakket dat is gebouwd door een derde partij—niet door het Chromium upstream-project. De Flatpak is bovendien geen hulp voor gebruikers die niet op x86-64 of 64-bit Arm-systemen zitten.

Het is technisch mogelijk voor Chromium-gebruikers om de browser zelf te bouwen en te compileren met behulp van de instructies van upstream, maar het lijkt erop dat het Chromium-project er niet veel om geeft om dat gemakkelijk te maken. Er is een pagina over het verkrijgen van de code, maar de links naar instructies voor Linux (evenals macOS en Windows) geven een 503-foutmelding. Een zoektocht naar instructies leidt naar een pagina, maar deze is ongedateerd, waardoor onduidelijk is of dit de meest actuele is. Uitgaande van het feit dat de instructies actueel en correct zijn, is het bouwen van Chromium volgens die richtlijnen een behoorlijk zware onderneming. Gebruikers kunnen vooraf gebouwde binaries downloaden van het project, maar alleen voor x86-64-systemen.

Andere distributies blijven natuurlijk Chromium-pakketten leveren, hoewel hun aanpak niet dezelfde flexibiliteit biedt als die van Gentoo. Het pakket van Fedora (dat wordt beschreven als "Een WebKit (Blink) aangedreven webbrowser die Google niet wil dat je gebruikt") is versie 154.0.8037.92—één versie achter de upstream release (154.0.8037.97) die op 1 oktober is gepubliceerd. Evenzo is het pakket in de security-repository van Debian momenteel dezelfde versie als die van Fedora, en de informatiepagina laat zien dat er ten minste 11 bekende CVE's zijn aangepakt in 154.0.8037.97. Bijhouden van Chromium is geen gemakkelijke taak.

Misschien vindt Gentoo een team dat bereid en in staat is om de last van het onderhouden van de Chromium ebuild te dragen volgens de standaarden die Gentoo-gebruikers verwachten. Wat er ook gebeurt, het lijkt onwaarschijnlijk dat Chromium in de tussentijd gemakkelijker te onderhouden wordt.

***

Discussie en aanvullende inzichten

In de nasleep van het bericht over de laatste rituelen ontstond een uitgebreide discussie onder de gemeenschap. Hieronder volgen de belangrijkste technische en organisatorische thema's.

Vergelijking met Firefox

Er werd gevraagd of het verpakken van andere browsers, zoals Firefox, even uitdagend is. De huidige Firefox-beheerder van Gentoo gaf aan dat Firefox ook veel werk is, maar makkelijker te beheren dan Chromium. De belangrijkste redenen hiervoor zijn:

• Upstream-ondersteuning: Mozilla lijkt meer oog te hebben voor downstream-distributies. Bron-tarballs verdwijnen minder vaak en ze staan open voor patches.
• Bouwsysteem: Hoewel Firefox ook een strakke releasecyclus heeft (nu elke 2 weken), zijn de wijzigingen aan de bouwkant meestal kleiner.
• Build-tijd: Firefox compileert aanzienlijk sneller dan Chromium, wat het testproces (met verschillende USE-flags en compilers) draaglijker maakt.

De rol van AI in pakketbeheer

Een verhit debat ontstond over de vraag of AI (LLM's) kan helpen bij het onderhoud van complexe pakketten.

• Voorstanders beweren dat AI kan helpen bij het overwinnen van hindernissen in arcane configuraties of het schrijven van repetitieve packaging-regels, waardoor de last voor vrijwilligers vermindert.
• Sceptici wijzen erop dat AI geen "innovatie" brengt, maar slechts synthetiseert uit bestaande data. Bovendien lost AI de fundamentele problemen niet op: de enorme compilatietijden, het gebrek aan medewerking van Google en het risico op "AI-slop" (onjuiste code die plausibel lijkt). Er is ook de zorg dat kennis gecentreerd raakt in het AI-model in plaats van bij de menselijke beheerders.

De "Google-methode" en Monorepos

Verschillende experts bespraken waarom Chromium specifiek zo moeilijk is. Google maakt gebruik van een gigantische monorepo en een eigen bouwsysteem (Bazel/Blaze).

• Deze aanpak werkt uitstekend voor Google, omdat zij beschikken over enorme interne infrastructuur met duizenden build-nodes en remote execution.
• Voor externe distributeurs is dit een nachtmerrie, omdat de workflow van Google niet is ontworpen voor systemen die vertrouwen op standaard system-compilers of offline-builds (zoals vereist door Gentoo).
• Er wordt gesuggereerd dat Google's onverschilligheid tegenover downstream-beheerders bijna als "intentioneel" aanvoelt, hoewel anderen dit toeschrijven aan een bedrijfscultuur waarin interne tooling belangrijker is dan publieke toegankelijkheid.

Alternatieve wegen

Voor gebruikers die Chromium willen blijven gebruiken op Gentoo, werden de volgende opties besproken:

• Flatpak: Een snelle oplossing, maar biedt geen controle over de build en is beperkt tot specifieke architecturen.
• Ungoogled-Chromium: Er zijn overlays (zoals die van PF4Public) die een relatief goed onderhouden versie van Ungoogled-Chromium aanbieden.
• Cross-distro samenwerking: Er wordt gewezen op het belang van het delen van patches tussen distributies (zoals Debian en Ungoogled-Chromium doen) om de individuele werklast te verminderen.