Fedora 31: “best mode” di default per DNF

DNF è il package manager di Fedora da ormai diverso tempo e recentemente la FESCo (Fedora’s Engineering and Steering Committee) ha approvato una modifica che verrà introdotta a partire da Fedora 31. La modifica riguarda il comportamento di DNF in caso di aggiornamenti, più precisamente l’opzione –best sarà quella utilizzata di default. Il comportamento attuale di DNF prevede che un pacchetto venga aggiornato alla versione più recente in cui tutte le dipendenze vengono soddisfatte. –best aggiorna un pacchetto alla versione più recente disponibile, a prescindere dalle dipendenze. Attivando questo comportamento di default, l’utente sarà immediatamente avvisato che un pacchetto aggiornato è disponibile, ma non è possibile risolvere le dipendenze. Esito: “fail early and fail fast”. Sì, proprio così. Gli sviluppatori hanno pensato bene che un comportamento del genere sarebbe più utile nel caso un aggiornamento di sicurezza non possa essere fatto a causa di dipendenze non risolte. DNF, come configurato al momento, ignorerebbe l’update all’ultima versione, non notificando l’utente. Sarà ovviamente prevista l’opzione –nobest e comunque altre possibilità di configurazione per il comportamento di DNF. Un primo feedback per questa proposta trova gli utenti a favore di questa variazione. Certo, DNF sarà comunque configurabile a piacimento (come sempre) ma solo […]

Continue reading

DNF conterà gli utenti Fedora

Il mese scorso Matthew Miller, presidente del Fedora Council, ha avanzato la proposta di includere da Fedora 30 in avanti un sistema per il quale venisse generato un UUID univoco al sistema utilizzato solo da DNF (il package manager di Fedora) per stimare con maggiore precisione il numero e la tipologia dei propri utenti. Questo sistema non conterebbe solo il numero degli utenti ma fornirebbe anche informazioni sul tipo di installazione come ad esempio la durata: un container o una cloud instance oppure un’installazione a lungo termine su una workstation/server. A dirla tutta, questa non è una novità; openSUSE infatti utilizza un metodo molto simile per generare metriche relative alle installazioni. Miller ha spiegato che, riuscendo ad avere informazioni più accurate, sarà possibile gestire meglio i fondi e le risorse dedicate al progetto, specialmente dopo l’acquisizione da parte di IBM nei mesi scorsi. La community non ha particolarmente gradito la proposta dell’utilizzo di un UUID legato al sistema ed il Fedora Project ha ascoltato. Un paio di giorni fa la FESCo (Fedora Engineering and Steering Committee) ha approvato le modifiche a DNF per consentirgli sì di generare metriche ma, invece di utilizzare un UUID, utilizzerà un countme bit che verrà […]

Continue reading

OpenMandriva: ritorno a RPM versione 4, ma anche novità DNF

Il 5 marzo un piccolo post sul forum di OpenMandriva (erede di Mandriva, o ancora prima Mandrake, Linux  – che i più anziani ricorderanno 😉 ) annuncia un passo indietro piuttosto importante: l’abbandono della versione 5 del sistema di pacchettizzazione RPM per un ritorno al – più usato – RPM4. A questo passo indietro corrisponde però una novità: l’adozione del tool dnf per la gestione dei pacchetti. Le motivazioni sono presto dette (prese dal post stesso): RPM4 è mantenuto rispetto a RPM5; RPM4 fornisce una suite intera per la gestione dei pacchetti o dei repository; DNF è uno standard largamente accettato per la gestione dei pacchetti (installazione, eliminazione, upgrade, etc.); Meno confusione, nessun altro brutto codice ed hack perl; Supporto dal canale ufficiale. Tutte motivazioni valide, e l’adozione dello stesso tool usasto da Fedora potrà permettere un passaggio più facile tra le due distribuzioni. C’è solo un problema in vista: l’adattamento dei vari tool di pacchettizzazione automatici usati finora potrà richiedere del lavoro e comportare dei pacchetti semplicemente rotti. Ma basta avere pazienza, e le cose, dopo, funzioneranno. O almeno si spera…

Continue reading