Debian, ancora sul vendoring

Su LWN è apparso un articolo riguardante la questione del vendoring dei pacchetti in Debian.

Il “vendoring” nei pacchetti, ossia la questione se inglobare le dipendenze nel package oppure soddisfarle da altri pacchetti, sembra scatenare diverse discussione nell’ultimo periodo. Abbiamo esaminato le preoccupazioni di Debian sulla pacchettizzazione di Kubernetes e la sua miriade di dipendenze Go a ottobre. Una discussione più recente nella comunità di quella distribuzione si è esaminano un altro ecosistema notoriamente ricco di dipendenze: le librerie JavaScript dal repository npm.
Anche gli ecosistemi basati su C non sono immuni dal problema, come abbiamo visto con iproute2 e libbpf a novembre; la discussione sul vendoring sembra destinata a non terminare nei prossimi anni.
Molti progetti applicativi, in particolare quelli scritti in linguaggi come JavaScript, PHP e Go, tendono ad avere un fadello piuttosto grande di dipendenze. Questi progetti in genere scaricano semplicemente versioni specifiche delle dipendenze necessarie al momento della compilazione. Funziona bene per progetti in rapido movimento che utilizzano raccolte di librerie e framework in continuo sviluppo, ma funziona piuttosto meno bene per le distribuzioni Linux tradizionali. Quindi svariati progetti di distribuzione hanno cercato di capire il modo migliore per incorporare questi tipi di applicazioni.

Questa volta, Raphael Hertzog ha sollevato la questione riguardo al Greenbone Security Assistant (gsa), che fornisce un front-end web allo scanner di vulnerabilità OpenVAS (che ora è noto come Greenbone Vulnerability Management o gvm). “la versione attualmente in Debian non funziona più con l’ultimo gvm quindi dobbiamo aggiornarla all’ultima versione upstream … ma l’ultima versione upstream ha modifiche significative, in particolare ora si basa su yarn o npm per scaricare tutti i moduli di cui ha bisogno (e ce ne sono molti, e non c’è modo di impacchettarli individualmente). La politica Debian vieta il download durante la compilazione, quindi non possiamo eseguire il sistema di compilazione a monte così com’è. “

Hertzog ha suggerito tre possibili soluzioni: raccogliere tutte le dipendenze nel pacchetto sorgente Debian (anche se ci sarebbero problemi nella creazione del file di copyright), spostare il pacchetto nel repository contrib e aggiungere un passaggio di post-installazione per scaricare le dipendenze, o rimuovere gsa da Debian interamente.
Sta lavorando all’aggiornamento di gsa come parte del suo lavoro su Kali Linux, che è derivata da Debian e che si concentra sui test di penetrazione e sul controllo della sicurezza.
Kali Linux non ha le stesse restrizioni sul download durante le build di Debian, quindi il pacchetto gsa di Kali può semplicemente usare il processo di compilazione upstream. Si preferirebbe mantenere gsa in Debian, “ma c’è solo così tanto lavoro che sono disposto a fare per raggiungere questo obiettivo”. Si chiedeva se avesse più senso per Debian considerare di allentare i suoi requisiti.
Ma Jonas Smedegaard ha offerto un altro possibile approccio: analizzare quali pacchetti sono necessari a gsa e quindi utilizzare i pacchetti Debian esistenti per quelle dipendenze o crearne di nuovi per quelli che non sono disponibili. Hertzog era convinto che questa strada non sarebbe stata seguita, ma Smedegaard ha affermato che il team JavaScript sta già lavorando a quel processo per più progetti.

Via Slashdot: https://linux.slashdot.org/story/21/01/13/1744228/debian-discusses-vendoring—-again