{"id":120153,"date":"2024-10-12T13:09:06","date_gmt":"2024-10-12T11:09:06","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-paketnogo-menedzhera-rpm-4-20-i-nachalo-razrabotki-rpm-6"},"modified":"2024-10-12T13:09:06","modified_gmt":"2024-10-12T11:09:06","slug":"vypusk-paketnogo-menedzhera-rpm-4-20-i-nachalo-razrabotki-rpm-6","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/vypusk-paketnogo-menedzhera-rpm-4-20-i-nachalo-razrabotki-rpm-6","title":{"rendered":"Uscita del gestore pacchetti RPM 4.20 e inizio dello sviluppo di RPM 6","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Dopo un anno di sviluppo, \u00e8 stato rilasciato il gestore di pacchetti RPM 4.20.0. Il progetto RPM4 \u00e8 sviluppato da Red Hat e viene utilizzato in distribuzioni come RHEL, Fedora, SUSE, openSUSE, ALT Linux, OpenMandriva, Mageia, PCLinuxOS e Tizen. Il codice del progetto \u00e8 distribuito sotto le licenze GPLv2 e LGPLv2. <\/p>\n
Il prossimo anno \u00e8 prevista la pubblicazione di una versione significativa di RPM 6, che utilizzer\u00e0 un nuovo formato di archivio. Questo nuovo formato consentir\u00e0, a differenza di quello attualmente in uso, di creare pacchetti di dimensioni superiori a 4 GB (superare questo limite \u00e8 importante poich\u00e9 il pacchetto SRC di Chromium \u00e8 vicino al limite e ha una dimensione di 3,7 GB). Nella nuova versione, sar\u00e0 anche possibile utilizzare il linguaggio C++ per lo sviluppo di RPM. Questa importante release coincider\u00e0 con il trentesimo anniversario del progetto \u2014 il 27 novembre 2025 si celebrer\u00e0 il 30\u00b0 anniversario dal primo commit in RPM. Le versioni RPM 5.x saranno saltate per evitare sovrapposizioni con il progetto RPM5, che non \u00e8 direttamente legato a RPM di Red Hat e si \u00e8 sviluppato con un team di sviluppatori indipendenti, fermo dal 2016. <\/p>\n
I miglioramenti pi\u00f9 significativi in RPM 4.20: <\/p>\n
\n
\u00c8 stata inclusa una nuova utility rpm2archive, che sostituisce l'utility rpm2cpio e faciliter\u00e0 ulteriormente la transizione verso il 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 \u00e8 stata sostituita da un link simbolico a rpm2archive.\n
\u00c8 stato proposto un sistema di build dichiarativo basato sull'uso della nuova direttiva \u00abBuildSystem\u00bb, attraverso la quale pu\u00f2 essere definito il sistema di build utilizzato per la creazione del pacchetto. Il codice sorgente viene automaticamente preparato, compilato e installato tenendo conto del sistema di build specificato, senza la necessit\u00e0 di definire separatamente nel file SPEC gli script di preparazione, build e installazione nei blocchi \u00ab%prep\u00bb, \u00ab%build\u00bb e \u00ab%install\u00bb. Nei RPM, i sistemi di build supportati sono definiti sotto forma di collezioni di macro.\n
L'idea principale \u00e8 che il formato dichiarativo delle configurazioni consenta agli sviluppatori di distribuzioni di creare macro separate per i processi di build standard, evitando di dover definire scenari ripetitivi in ciascun pacchetto. Ad esempio, invece di definire le sequenze di comando per configure e make per i programmi che utilizzano Autotools, ora basta indicare \u00abBuildSystem: autotools\u00bb e non \u00e8 necessario includere le sezioni \u00ab%prep\u00bb, \u00ab%build\u00bb e \u00ab%install\u00bb. Attualmente, macro di questo tipo sono state preparate per Autotools e CMake. Se \u00e8 necessario realizzare comportamenti non standard, ai manutentori dei pacchetti \u00e8 data la possibilit\u00e0 di collegare le proprie macro per sovrascrivere diverse fasi della creazione del pacchetto. <\/p>\n
\u00c8 stata aggiunta la supporto per l'aggiunta di sezioni aggiuntive con i comandi di preparazione, assemblaggio, installazione, configurazione, pulizia e verifica, che integrano le sezioni di base %prep, %conf, %build, %install, %check e %clean. Per avviare uno script aggiuntivo prima dell'esecuzione del codice dalla sezione di base \u00e8 stata proposta l'opzione «-p», e dopo la sezione di base \u2014 l'opzione «-a». Tali sostituzioni possono rivelarsi utili per modifiche mirate nel comportamento durante l'utilizzo della modalit\u00e0 di assemblaggio dichiarativa sopra descritta.\n
\u00c8 consentito includere nei file SPEC parti dinamicamente generate direttive e sezioni che non influenzano il processo di compilazione.\n
\u00c8 stata aggiunta la macro %builddir, e implementata la possibilit\u00e0 di legare i propri directory di compilazione a pacchetti separati gestita tramite RPM.\n
\u00c8 stato proposto un nuovo protocollo «multi-file», che accelera notevolmente la generazione delle dipendenze.\n
Nel comando rpm \u00e8 stata aggiunta l'opzione «—json» per visualizzare i risultati delle query in formato JSON.\n
\u00c8 stato aggiunto il plugin rpm-plugin-unshare, che fornisce isolamento per gli script eseguiti nelle sezioni di compilazione, 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, nonch\u00e9 di utilizzare directory private separate \/tmp e \/home per proteggere in caso di operazioni non sicure con file temporanei durante la compilazione dei pacchetti.\n
\u00c8 stato proposto un API pubblico per lo sviluppo di plugin, che manterr\u00e0 la compatibilit\u00e0 tra le versioni. In precedenza, l'API per i plugin era destinata solo all'uso interno e poteva cambiare da una versione all'altra.\n
Nel comando rpmkeys sono state aggiunte le opzioni «—list» e «—delete».\n
Nel comando rpmsign \u00e8 stata aggiunta la supporto per la creazione di firme digitali per i pacchetti, utilizzando chiavi ECDSA.\n
\u00c8 stato migliorato il supporto per le costruzioni ripetibili. \u00c8 stato aggiunto il macro «%build_mtime_policy», che consente di gestire il contenuto delle etichette aggiunte durante la costruzione con il tempo (utilizzando il valore clamp_to_source_date_epoch \u00e8 possibile usare un'etichetta fissa, mentre con clamp_to_buildtime si pu\u00f2 specificare il tempo reale di costruzione).\n
Nei file sysusers.d \u00e8 consentito aggiungere righe per definire i membri del gruppo.\n
Assicurata la corretta e distribuzione-indipendente supporto dei file debuginfo.\n
\u00c8 stata dichiarata obsoleta la sintassi dei macro %patchN (senza spazio prima di N), il cui uso ora porter\u00e0 a un errore (dovrebbe essere utilizzata la sintassi «%patch N» o «%patch -P N», dove N \u00e8 il numero della patch).\n
Rimosso il parser obsoleto OpenPGP.\n
I generatori di dipendenze per Perl e Python ABI sono stati spostati in repository separati. <\/ul>\n