Rilascio del gestore di pacchetti RPM 4.20 e inizio dello sviluppo di RPM 6

Dopo un anno di sviluppo, è stata rilasciata la versione 4.20.0 del gestore di pacchetti RPM. Il progetto RPM4 è sviluppato da Red Hat ed è utilizzato in distribuzioni come RHEL, Fedora, SUSE, openSUSE, ALT Linux, OpenMandriva, Mageia, PCLinuxOS e Tizen. Il codice del progetto è distribuito sotto le licenze GPLv2 e LGPLv2.

L'anno prossimo si prevede la pubblicazione di una nuova importante versione di RPM 6, che utilizzerà un nuovo formato di archivio, in grado di creare pacchetti superiori a 4 GB, superando il limite attuale del formato cpio (questo è importante poiché il pacchetto SRC di Chromium si avvicina al limite e ha una dimensione di 3.7 GB). Nella nuova versione, si prevede anche di consentire l'uso del linguaggio C++ per lo sviluppo di RPM. Questa nuova significativa versione sarà legata al trentesimo anniversario del progetto, in quanto il 27 novembre 2025 ricorrerà il trentesimo anniversario dal primo commit in RPM. Le versioni RPM 5.x saranno saltate per evitare sovrapposizioni con il progetto RPM5, che non è direttamente correlato a RPM di Red Hat, sviluppato da un team di sviluppatori indipendenti e non aggiornato dal 2016.

I miglioramenti più significativi in RPM 4.20:

  • È stata inclusa una nuova utility rpm2archive, che sostituisce l'utility rpm2cpio e semplificherà in futuro la migrazione al nuovo formato di pacchetti che non utilizza cpio. A differenza di rpm2cpio, la nuova utility converte il file RPM non in un archivio cpio, ma in un archivio nel formato tar, compresso con gzip. La vecchia utility rpm2cpio è stata sostituita da un collegamento simbolico a rpm2archive.
  • È stato proposto un sistema di build dichiarativo, basato sull'utilizzo della nuova direttiva "BuildSystem", attraverso la quale è possibile definire il sistema di build da utilizzare nella creazione del pacchetto. Il codice sorgente viene automaticamente preparato, compilato e installato tenendo conto del sistema di build specificato, senza la necessità di definire separatamente negli script di SPEC i passaggi di preparazione, build e installazione nei blocchi "%prep", "%build" e "%install". Nei pacchetti RPM, i sistemi di build supportati sono definiti sotto forma di collezioni di macro.

    L'idea principale è che il formato di configurazione dichiarativo permetterà agli sviluppatori di distribuzioni di creare macro separate per i processi standard di compilazione, evitando di definire scenari ripetitivi in ogni pacchetto. Ad esempio, invece di definire le sequenze di comando configure e make per i programmi che utilizzano Autotools, ora è sufficiente specificare "BuildSystem: autotools" e saltare le sezioni "%prep", "%build" e "%install". Attualmente, macro come queste sono pronte per Autotools e CMake. Se è necessaria l'implementazione di un comportamento non standard, i manutentori dei pacchetti hanno la possibilità di connettere le proprie macro per sovrascrivere le diverse fasi della formazione del pacchetto.

  • È stata aggiunta la possibilità di allegare sezioni aggiuntive con comandi di preparazione, costruzione, installazione, configurazione, pulizia e verifica, che completano le sezioni di base %prep, %conf, %build, %install, %check e %clean. Per avviare uno script aggiuntivo prima di eseguire il codice dalla sezione di base è stata proposta l'opzione "-p", e dopo la sezione di base — l'opzione "-a". Questi sostituti possono rivelarsi utili per una regolazione fine del comportamento durante l'uso della modalità di costruzione dichiarativa sopra descritta.
  • È consentito includere direttive e sezioni nelle parti SPEC generate dinamicamente, che non influenzano il processo di costruzione.
  • È stato aggiunto il macro %builddir e implementata la possibilità di gestire attraverso RPM il collegamento delle proprie directory di build a pacchetti separati.
  • È stato proposto un nuovo protocollo "multi-file", che accelera notevolmente la generazione delle dipendenze.
  • È stata aggiunta all'istruzione rpm l'opzione "—json" per l'output dei risultati delle query in formato JSON.
  • È stato aggiunto il plugin rpm-plugin-unshare, che fornisce isolamento per gli script eseguiti nelle sezioni di costruzione, utilizzando gli spazi dei nomi in Linux. Ad esempio, il plugin consente di vietare l'accesso alla rete e limitare l'accesso al file system, oltre a utilizzare directory private separate `/tmp` e `/home` per proteggere nel caso di operazioni non sicure con file temporanei durante la costruzione dei pacchetti.
  • È stato proposto un API pubblica per lo sviluppo dei plugin, che garantirà la compatibilità tra le versioni. In precedenza, l'API per i plugin era destinata solo all'uso interno e poteva cambiare da una versione all'altra.
  • Sono state aggiunte le opzioni «—list» e «—delete» al comando rpmkeys.
  • Nel comando rpmsign è stata aggiunta la possibilità di creare firme digitali per i pacchetti, utilizzando chiavi ECDSA.
  • Migliorato il supporto per le build ripetibili. È stato aggiunto il macro «%build_mtime_policy», che consente di gestire il contenuto delle etichette aggiunte durante la costruzione in base al tempo (tramite il valore clamp_to_source_date_epoch è possibile utilizzare un'etichetta fissa, mentre tramite clamp_to_buildtime si può specificare l'orario effettivo della costruzione).
  • Nei file sysusers.d è consentito aggiungere righe per definire i membri del gruppo.
  • È garantito un supporto corretto e indipendente dalla distribuzione per i file debuginfo.
  • È stato dichiarato obsoleto il sintassi delle macro %patchN (senza spazio prima di N), il cui utilizzo ora comporterà errori (si deve usare la sintassi «%patch N» o «%patch -P N», dove N è il numero della patch).
  • È stato rimosso il parser OpenPGP obsoleto.
  • I generatori di dipendenze per Perl e Python ABI sono stati spostati in repository separati.

Fonte: opennet.ru

Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server 🔥 Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server | ProHoster