{"id":123368,"date":"2025-04-03T21:05:07","date_gmt":"2025-04-03T19:05:07","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/utverzhdyon-perehod-fedora-43-na-paketnyj-menedzher-rpm-6-smena-lidera-fedora"},"modified":"2025-04-03T21:05:07","modified_gmt":"2025-04-03T19:05:07","slug":"utverzhdyon-perehod-fedora-43-na-paketnyj-menedzher-rpm-6-smena-lidera-fedora","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/novosti-interneta\/utverzhdyon-perehod-fedora-43-na-paketnyj-menedzher-rpm-6-smena-lidera-fedora","title":{"rendered":"Approvato il passaggio di Fedora 43 al gestore pacchetti RPM 6. Cambio di leadership in Fedora.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Il comitato FESCo (Fedora Engineering Steering Committee), responsabile della parte tecnica dello sviluppo della distribuzione Fedora Linux, ha approvato la transizione al gestore pacchetti RPM 6 nella release autunnale di Fedora 43. Il rilascio di RPM 6.0 \u00e8 previsto per il terzo trimestre del 2025. <\/p>\n
La branca di RPM 6 \u00e8 notevole per il supporto del nuovo formato (RPM 6), che consente di creare pacchetti di dimensioni superiori a 4 GB (superare questo limite \u00e8 importante poich\u00e9 il pacchetto SRC con Chromium \u00e8 vicino al limite e ha una dimensione di 3,7 GB). Il formato RPM 6 utilizza campi a 64 bit, aggiorna le strutture relative alla crittografia e aggiunge informazioni MIME sui file. La versione RPM 5 \u00e8 stata saltata per evitare sovrapposizioni con il progetto RPM5, che non \u00e8 correlato a RPM di Red Hat ed \u00e8 stato sviluppato da sviluppatori indipendenti. <\/p>\n
Il supporto per il formato RPM 4, che utilizza cpio, sar\u00e0 mantenuto nella sua interezza. Inoltre, il ramo RPM 6 non impone il passaggio al nuovo formato dei pacchetti, e le distribuzioni avranno la libert\u00e0 di rimanere nel formato RPM 4. Ad esempio, Fedora 43 verr\u00e0 fornita con il gestore di pacchetti RPM 6.0, ma il formato dei pacchetti rimarr\u00e0 per ora RPM 4. Per coloro che desiderano passare al nuovo formato, nel ramo RPM 4.x \u00e8 stato aggiunto il supporto per la lettura e l'installazione dei pacchetti in formato RPM 6. <\/p>\n
Tra le modifiche significative in RPM 6 spicca l'attivazione predefinita della verifica dell'autenticit\u00e0 dei pacchetti mediante firma digitale. Per garantire che la verifica obbligatoria della firma non complichi l'installazione di pacchetti compilati in modo autonomo, in RPM 6 \u00e8 stata aggiunta alla utility rpmbuild la supporto per la generazione automatica di firme locali durante la compilazione. \u00c8 stata inoltre prevista un'opzione «—nosignature» che consente di forzare l'installazione del pacchetto senza verificare la firma. <\/p>\n
Tra le altre modifiche: nel processo di sviluppo \u00e8 consentito l'uso di codice in C++ (C++20); \u00e8 possibile utilizzare pi\u00f9 firme OpenPGP per ciascun pacchetto; \u00e8 stata interrotta la supporto per gli hash MD5, SHA1 e DSA; \u00e8 cessato il supporto per il formato RPM 3 obsoleto. Le funzionalit\u00e0 della utility rpmkeys per la gestione delle chiavi sono state ampliate, ad esempio, per aggiornare le chiavi OpenPGP \u00e8 possibile utilizzare il comando «rpmkeys —import». La utility rpmkeys stessa \u00e8 ora considerata in Fedora come lo strumento principale per la gestione del repository delle chiavi per RPM (l'uso di gpg-pubkey \u00e8 stato dichiarato obsoleto). In alternativa a GnuPG, \u00e8 stata fornita la possibilit\u00e0 di utilizzare il toolkit Sequoia-sq, scritto in Rust. <\/p>\n
Inoltre, si segnala la nomina di un nuovo leader per il progetto Fedora. Invece di Matthew Miller, che ha ricoperto il ruolo di leader dal 2014, \u00e8 stato nominato Jef Spaleta, coinvolto nel lavoro fin dai tempi in cui il progetto Fedora non era ancora sotto l'egida di Red Hat. In passato, Jef ha fatto parte del consiglio di amministrazione di Fedora per alcuni anni come rappresentante della comunit\u00e0. <\/p>\n
Il Leader di Fedora \u00e8 un ruolo ufficiale all'interno dell'azienda Red Hat. Non viene eletto tramite voto dei membri della comunit\u00e0, ma nominato dal precedente leader del progetto e approvato da Red Hat. Il coordinamento dello sviluppo della distribuzione \u00e8 gestito da un consiglio di gestione composto da 4 rappresentanti di Red Hat e 5 sviluppatori indipendenti della comunit\u00e0. Al leader del progetto vengono richieste diverse qualit\u00e0, come alta qualificazione, esperienza nel lavoro di comunit\u00e0, capacit\u00e0 di prendere decisioni e ascoltare le opinioni degli altri. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"