Upgrade: esperienze e strategie...

[joe]

Con il presente topic, mi piacerebbe raccogliere qualche opinione ed esperienza riguardo la questione del passaggio ad una versione più recente del proprio sistema, con particolare riferimento a Slackware.

Per quanto mi riguarda l'unico passaggio che ho affrontato è stato da slackware-11.0 a slackware-12.1 e l'ho portato a termine, installando su una nuova partizione la 12.1, quindi piano piano, ricostruendo l'ambiente che mi ero creato nella 11.0.
Attualmente ho ancora una partizione dove risiede la slack-11.0 e una seconda in cui ho l'attuale sistema 12.1.

Questa migrazione non è stata indolore e ha richiesto da parte mia la riconfigurazione di un bel po' di cose. D'altra parte è normale visto che ho messo in piedi una installazione pulita e l'ho poi corredata di diversi scripts che uso da tempo, files di configurazione di software più o meno complicati da configurare, mi viene in mente il server news inn, mutt, la configurazione del kernel per gestire lo scaling della mia cpu (un p4 piuttosto rumoroso) per utilizzare i driver video proprietari eccecc.

D'altra parte, penso che per uso desktop sia buona norma, dopo un po' di tempo apprestarsi all'upgrade, in quanto qualora si voglia installare nuovo software attraverso compilazione, può capitare di trovarsi con versioni di librerie vecchie non in grado di reggere software troppo recenti. Oppure semplicemente si vuole passare a qualche pacchetto più recente di un certo software senza doverlo compilare ecc ecc.

Proprio in questi giorni stavo pensando di eseguire un upgrade della mia distribuzione, cogliendo anche l'occasione per riorganizzare il partizionamento dell'hd.
Però questa volta vorrei partire dal mio attuale sistema, mantenedo così tutti gli scripts che uso, le configurazioni ecc ecc.
Prima di accingermi ad un'operazione così "invasiva" buttandomi a pesce, vorrei discuterne un po' con voi, sperando che emergano alcune problematiche e possibili strategie che scaturiscono dalla vostra esperienza e competenza.

Innanzitutto vi espongo la mia idea:

1- installazione su HD esterno del sistema attuale, prova.
1.a- aggiornamento del sistema.
1.b- configurazione e ritocchi.
2- installazione su partizione di slack-11, rimuovendola.
3- backup sistema slackware 12.1 attuale su HD esterno.
4- allargamento partizione della nuova slackware.

Al di là di questi step, volti a non restare senza un sistema funzionante, vorrei focalizzare l'attenzione sul primo punto. In particolare sui 1.a, 1.b.
Vorrebbe essere quello il centro di questa discussione.

Ora, il punto 1.a è più o meno difficile a seconda di quelle che sono le caratteristiche delle varie installatoni del software presente.
Ad esempio, ci possiamo trovare nel caso di un sistema puro, costituito solo da pacchetti di Pat...in tal caso l'operazione d'aggiornamento dovrebbe essere piuttosto facile, o in ogni caso, abbastanza meccanica. Certo, questo è un fortunato caso limite....ma quasi sicuramente non rispecchia la situazione di un comune sistema desktop...ricco di software di terze parti, installato da pacchetti rilasciati da communities come la presente, creati in proprio via compilazione ancora, software installato a colpi di make install...che è difficile gestire anche in caso di semplice disinstallazione.

La presente discussione vorrebbe essere proprio una raccolta di problematiche, idee, esperienze abitudini e strategie che perseguano una quanto piu possibile semplice operazione di upgrade, ma soprattutto che porti ad ottenere un nuovo sistema aggiornato, coerente e per quanto possibile pulito...ovviamente con cui ci si ritrovi praticamente col sistema di sempre, configurato, limato e reso comodo per le nostre abitudini di tutti i giorni, evitando o comunque riducendo al minimo il "trauma" della migrazione.
Chissà che possa portare anche a nuovi spunti per integrare alcuni scritti dedicati appunto all'upgrade della slack.

[DanBadJar]

Mi sembra un ottimo topic.
Per quello che mi riguarda però, io faccio ancora alla vecchia maniera, ovvero:

1) Mi segno la configurazione e la roba "importante", documentandola.
2) Parto con una qualsiasi distro live e copio i TUTTI i file della partizione da aggiornare su un altro disco di backup.
In informatica si può sbagliare, ma quel che conta ancora di più è la capacità di fare rollback
3) Installo la nuova Slackware
4) Copio i file di configurazione del punto 1 sulla nuova installazione.

A qualcuno potrà sembrare un metodo un po' grezzo, ma secondo me aiuta a rinfrescare la memoria su cosa e come è installato sul sistema!
Ad esempio: ho un server in produzione che è li da anni. Per un qualsiasi motivo devo aggiornare il sistema. Bene! E' un'ottima occasione per fare un po' di ripasso!

[conraid]

hai letto i miei documenti nel wiki?
così almeno guardi se c'è già una possibile soluzione che ti interessa, ed al limite la integriamo
altrimenti facciamo doppio lavoro, visto che ne abbiamo parlato varie volte di queste cose e partire da una "base" già acquisita mi sembra meglio

il tutto in mia umile opinione

[ZeroUno]

evitando o comunque riducendo al minimo il "trauma" della migrazione.

Mica tanto...
La procedura di aggiornamento di slackware è studiata per l'aggiornamento da 12.2 a 13.0; già così si presentano notevoli complicazioni data la massa di pacchetti aggiornati, path stravolti... Dalla 12.1 alla 13.0 equivale ad una nuova reinstallazione senza speranza di poter fondere in modo semplice i file .new e con la probabilità di mantenere sporcizia quà e là. Personalmente dopo l'aggiornamento (anche da current su qualche pc) X mi crashava spesso e volentiere finchè non ho reinstallato. Tutte le ricompilazioni vanno rifatte perchè sono state aggiornate le glibc da allora (mi sembra), così anche gli script shell avranno probabilmente necessità di ritocchi; la configurazione del kernel personalizzato è tutta da rivedere perchè credo che il .config cambi un po' da 2.6.24 a 2.6.29.
Personalmente ho provato l'aggiornamento di slackware da 12.0 a 13.0; il primissimo passo è stato quello di prendere i sorgenti di xz e tar e ricompilarli perchè le glibc di slackware 12.0 (e forse anche quelle di 12.1) non li reggono.

Quindi i passi consigliati (da me) sono, senza installarsi una distribuzione di appoggio:
1) boot cd
2) mount /dev/... /mnt
3) mkdir /mnt/old
4) mv /mnt/* /mnt/old
5) mkdir /mnt/lost+found
6) umount /mnt
7) setup

Al momento della scelta della partizione specificare di NON formattare.

Al riavvio prendere tutte le configurazioni e gli script personalizzati e le home da /old e fonderli con la nuova distro.
Se qualcosa non ha funzionato, ripristinare /old

Ciao
01

[joe]

hai letto i miei documenti nel wiki?

Eh... qualcosa, ma magari qualcosa di utile non l'ho visionato.
Come vedi ho psto l'accento sulle problematiche che riguardano un sistema misto, comprensivo di software non compreso nel repo di Pat...magari con pacchetti creati in locale ecc. Il mio topic vorrebbe raccogliere esperienze circa la gestione del sistema, evidenziando le strategie che ognuno ha elaborato per mantenere il proprio sistema anche e soprattutto in vista di un eventuale upgrade.
Per fare un esempio, già la risposta di ZeroUno ha evidenziato diverse problematiche e ha riportato le abitudini dell'utente nella gestione del sistema...idem per quanto riguarda la risposta di BanDaJar, in ogni caso probabilmente occorrerà entrare un po' più nello specifico, magari anche con qualche esempio, ma la direzione mi pare giusta.

Quindi, non vorrei che questo topic fosse un doppione delle tue guide ed how-to(s), bensì un'approfondimento sul tema:
"sistema misto: buone regole di manutenzione per non <<andarci a bagno>> ad ogni upgrade"

così almeno guardi se c'è già una possibile soluzione che ti interessa, ed al limite la integriamo
altrimenti facciamo doppio lavoro, visto che ne abbiamo parlato varie volte di queste cose e partire da una "base" già acquisita mi sembra meglio

Non posso che trovarmi d'accordo ovviamente, quindi nel frattempo mi rileggo meglio le tue guide. Anche se da quanto ho visto fin'ora (ma ripeto, è meglio rileggerle con più attenzione) non entrano nello specifico della gestione (anche perchè probabilmente andrebbero fuori tema) soffermandosi invece giustamente di più sull'operazione di upgrade propriamente detta.

Cerco di chiarire:
1- installo slackware e la uso per molto tempo, configrando il sistema, aggiungendo software che mi serve, compilandolo cercando sempre di pacchettizzarlo per sfruttare i pkgtools e non impazzire con un sistema "sporco" ecc ecc.
2- Dopo molto tempo mi accorgo che il software recente vuole un sistema più moderno e decido di aggiornare.

Per aggiornare intendo genericamente passare ad una versione successiva di slackware, stabile o current che sia. Quindi sia con installazione pulita si con upgrade.

3- mi ritrovo con un sistema nuovo ma spgliato di tanta roba che mi ero configurato, compilto ecc ecc..
4- mi chiedo dunque, come avrei dovuto mantenere il mio sistema per passare alla nuova versione non perdendo tutto il lavoro di arricchimento e limatura fatto al punto (1) ???

Spero che il topic non si sovrapponga alle guide di cui parlavi. Mi pare un argomento molto vasto che comprende sì anche le modalità di upgrade, ma va al di là della procedura meccanica di aggiornamento descritta nelle guide.

[conraid]

la tua situazione è proprio la mia, e quella per quale ho creato quelle guide
altrimenti basterebbe leggere upgrade.txt od usare slackpkg

naturalmente non ho preso in considerazione upgrade da 10 a 13 per esempio, ma solo da versione in versione, quindi i pacchetti rimossi e aggiunti devi cercarteli nei vari changes_and_hits.txt o usare slackpkg (facendo attenzione all'opzione clean-system)

[joe]

Capisco ma come la mettiamo con il software aggiunto da terze parti o pacchettizzato in proprio?

[conraid]

Capisco ma come la mettiamo con il software aggiunto da terze parti o pacchettizzato in proprio?

in che senso come la mettiamo?
tu prima aggiorni la slackware (non in metodo full, se segui la guida lo spiego) e dopo pensi al resto tramite repository o tramite tue ricompilazioni.

l'how-to lo feci proprio per evitare l'aggiornamento brutale e non installare software come sendmail per esempio.

non capisco però cosa vuoi dire

[joe]

tu prima aggiorni la slackware (non in metodo full, se segui la guida lo spiego) e dopo pensi al resto tramite repository o tramite tue ricompilazioni.

Intendevo esattamente questo punto:

Mettiamo di avere installato 100 pacchetti da slacky.eu che in generale potrebbero non funzionare sulla nuova slackware.
In pratica dovrò aggiornare quei pacchetti con i nuovi presenti nel repo di slacky, giusto? Tra parentesi non è detto che siano ancora stati pacchettizzati tutti per la nuova versione...
In soldoni come operi tu per aggiornare tutti quei paccheti? Voglio dire, io non ricorderei a memoria quali pacchetti di slacky avevo installato.... mi troverei davanti al rischio di trovarmi nel sistema alcuni pacchetti di slacky ancora relativi alla vecchia versione di slackware.... non so se mi spiego.
Tipo, facciamo un esempio, mettiamo che abbia installato questo pacchetto nella vecchia slack:
cairo-perl-1.060-i486-2sl.tgz
(È solo un esempio, non so neanche a cosa serva, ma non ci interessa in questo discorso...)
Ciò che conta è che quel pacchetto è stato creato su una slack-12.1, con le sue librerie, una certa versione di glibc, un certo kernel ecc ecc, cioè in generale potrebbe non funzionare sulla nuova versione di slack...sia essa la 12.1 o addirittura la 13.0.
Mettiamo che io non ricordi di aver installato quel pacchetto... cosa comune se si hanno molti pacchetti di terze parti. Ecco, al momento dell'aggiornamento, mi ritroverò con una bella slackware 12.2 o 13.0, nella quale tutti i pacchetti ufficiali sono apposto,a ggiornati ecc. Ma quel pacchetto potenzialmente non funzionerà, e magari non farà funzionare neanche altra roba.
Questo è un problema a mio modo di vedere.
Spero di avere chiarito nello specifico la questione e mi piacerebbe capire come fai tu e gli altri a ritrovarsi con un sistema aggiornato, non solo nei pacchetti ufficiali, ma anche per quanto riguarda quelli terzi... Non ditemi che andate a memoria, daccordo il discorso dei subgenii, ma non venitemela a raccontare così grossa!

[ZeroUno]

ls -lt /var/log/packages lanciato dopo l'aggiornamento dovrebbe bastare.
in generale per individuare velocemente pacchetti slacky o linuxpacakges (non funge per alcuni di slackbuilds.org):
ls /var/log/packages/*[a-zA-Z]
Tutti i pacchetti "certificati" slacky hanno una sigla dopo il numero di revisione.

eventualmente usi slackyd o slapt-get per sapere se ci sono aggiornamenti e se sono ripacchettizzati per slackware 13

Per quanto riguarda quelli compilati da te, abbi l'accortezza di compilarteli con uno slackbuild che poi inserirai nel pacchetto stesso.
A differenza dei pacchetti linuxpackages, quelli certificati slacky hanno tutti lo slackbuild in /usr/doc/...
Una volta che hai lo slackbuild il gioco è fatto.

Più complicate sono le configurazioni.
In caso di upgrade ti ritroverai con un mare di file .new e lì devi discriminare tu quali sono quelli che hai modificati. Magari può tornare utile che quando fai la modifica ad un file ne crei prima il backup (rename in .orig), così all'occorrenza fai una ricerca per *.orig e sai quali hai modificato. una diff con il corrente ti dice che modifiche hai fatto. una diff del .orig col .new ti dice le modifiche apportate con l'upgrade del pacchetto; fai la fusione delle due modifiche ed hai il nuovo file.

Personalmente una volta fatta l'installazione della nuova slackware come dicevo prima, mi tengo la copia della vecchia per un bel po' di tempo, fino a che sono sicuro di non aver dimenticato niente (la home non me la copio subito tutta perchè ne approfitto per fare pulizia); dopo comincio a far fuori bin,sbin e le altre piano piano fino a che sono sicuro al 100% di non aver dimenticato nulla.

Ciao
01

[conraid]

tu prima aggiorni la slackware (non in metodo full, se segui la guida lo spiego) e dopo pensi al resto tramite repository o tramite tue ricompilazioni.

Intendevo esattamente questo punto:

Mettiamo di avere installato 100 pacchetti da slacky.eu che in generale potrebbero non funzionare sulla nuova slackware.
In pratica dovrò aggiornare quei pacchetti con i nuovi presenti nel repo di slacky, giusto? Tra parentesi non è detto che siano ancora stati pacchettizzati tutti per la nuova versione...
In soldoni come operi tu per aggiornare tutti quei paccheti?

io me li ricompilo da solo, quelli che non funzionano, ho il mio repository personale e gestisco quello

non pensare che tutti vadano ricompilati (naturalmente se il software è cambiato la scelta sta a te). Ci sono pacchetti in Slackware che sono li da versioni e versioni. Certo è che se cercano una particolare versione di una libreria ed ora non c'è più, vanno ricompilati

Una volta aggiornata la Slackware tramite uno dei metodi di preferisci, utilizzi slackyd per esempio.
comunque per capire i pacchetti non slackware puoi usare qualche riga di bash per trovare i pacchetti che hanno un tag come ti ha già detto ZeroUno

Se non tutti non sono stati ancora impacchettati, o fai da solo o aspetti, purtroppo non c'è altro modo

[joe]

Le indicazioni che avete dato, vanno appunto nella direzione che avevo in mente anche io.
Secondo me ci sono già elementi a sufficenza per fare una piccola sintesi sulla buona condotta dell'amministratore di sistema desktop casalingo. Semplici strategie, che evitano comunque grattacapi in fase di passaggio (attraverso upgrade o reinstallazione) ad una versione più recente di slack.
Inizierei pertanto a buttare giù qualche considerazione evidenziando i diversi casi che possiamo trovarci di fronte. Ho messo insieme ciò che avete suggerito con quello che mi veniva in mente...sicuramente c'è parecchio da aggiungere e da correggere. Insomma, prendete tutto con le pinze considerando quanto segue come un punto di partenza.

Innanzitutto suddividerei la questione files di configurazione dall'aggiornamento pacchetti. Sono due aspetti ovviamente correlati, ma mentre l'aggiornamento pacchetti è affidato ai tools di aggiornamento/installazione/rimozione, per i files di configurazione dobbiamo sbrigarcela da noi, verificando se è il caso di eliminare i vecchi sostituendoli con i nuovi, se è il caso di editarne qualcuno, oppure se si può mantenere la vecchia versione.
A livello cronologico durante la procedura di passaggio a nuova versione prima si aggiornano i pacchetti, poi si penserà ai files di configurazione. Ho però inziato a buttare giù qualcosa circa i files di configurazione, per cui intanto posto questo.

Aggiungo inoltre come premessa che ho voluto spendere qualche parola anche sul passaggio a nuova versione attraverso installazione pulita. Ritengo che sia comunque una via valida e in ogni caso un'alternativa all'upgrade inteso senso stretto. Ho cercato di inquadrare un attimo il discorso ponendo come obiettivo quello di giungere da un sistema fresco ad uno quanto più simile nella configurazione e personalizzazione al nostro vecchio sistema. Senza nessuna pretesa di essere completo...anche qui prendiamolo come un punto di partenza da integrare con aggiunte correzione tagli ecc.


I - FILES DI CONFIGURAZIONE:

• I.a- l'aggiornamento con upgradepkg, comporta la creazione di nuovi files di configurazione targati .new.
  
  quindi, il generico pacchetto pippo-old che aveva il file di configurazione pippo.config, grazie all'aggiornamento viene sostituito col pacchetto pippo-current e tramite upgradepkg il vecchio file di configurazione verrà affiancato (non sovrascritto ovviamente) da uno nuovo: pippo.config.new.
  Il problema...ci sono vari casi
  
  1- Il formato del file di configurazione di pippo-old è coerente con la nuova versione del software pippo-new
  
  • 1.a- pippo.config non è stato ritoccato da noi ---> pippo.conf = pippo.conf.new ---> possiamo rimuovere pippo.conf.new oppure rimpiazzare il vecchio config con il ".new", tanto i due file sono uguali.
    
    1.b- pippo.config è stato personalizzato ---> pippo.conf \= pippo.conf.new ---> possiamo eliminare pippo.conf.new in tal modo manteniamo la nostra configurazione di sempre.
  2- Il formato del file di configurazione di pippo-old NON è coerente con la nuova versione del software pippo-new
  • 2.a- pippo.config non è stato ritoccato da noi ---> pippo.conf \= pippo.conf.new ma entrambi usano le impostazioni di default del software pippo ---> possiamo rimpiazzare il vecchio config con il ".new", senza mettere mano al nuovo file: il software pippo dovrebbe funzionare come prima.
    
    2.b- pippo.config è stato personalizzato ---> pippo.conf \= pippo.conf.new ---> rimpiazzare pippo.conf con pippo.conf.new E "tradurre" la vecchia configurazione nel nuovo formato.
  I casi 1.a e 2.a sono i più semplici da gestire in quanto in tali casi possiamo rimpiazzare il nuovo file di configurazione col vecchio senza porci alcun problema...in quanto se il nostro pippo funzionava prima con la configurazione di default, perchè non dovrebbe continuare a funzionare con la nuova versione e rispettivo file di configurazione? Certo murphy è sempre dietro l'angolo mi direte...
  
  
  I casi 1.b e 2.b devono essere cercati e occorre poi valutare se siamo nel caso 1 o 2.
  Il problema grosso sta qui.
  E la soluzione che giustamente propone ZeroUno, passa per una oculata gestione:
  ogni volta che modifichiamo un file di configurazione dovremmo mantenere l'originale backuppandolo per esempio così pippo.conf.orig.
  In questo modo all'aggiornamento troveremo:
  
  pippo.conf
  pippo.conf.orig
  pippo.conf.new
  
  È evidente che solo i casi in cui esiste il file di configurazione .orig indicano che il software è stato personalizzato. Per tutti gli altri si ricade nei punti (a).
  Quindi SE la nostra gestione del sistema è stata oculata seguendo questa semplice regola, allora, possiamo risolvere il probelma dei files di configurazione come segue:
  
  - cerchiamo i files *.orig troveremo pippo.orig per esempio, e significherà che pippo.conf è stato personalizzato
  - per capire se il formato è stato mantenuto o rivisto per la nuova versione si confronta con diff pippo.conf.orig con pippo.conf.new, se non ci sono differenze il formato è sicuramente coerente tra le due versioni per cui siamo nel caso 1.b e possiamo semplicemente buttare il .new
  - se il responso di diff è positivo, non si può dire a prescindere se il pippo.conf è coerente col pippp.conf.new:
  * se le differenze sono veramente minime molto probabilmente ci troviamo ancora nel caso 1.b
  * se le differenze sono molte occorre visionare il file ed eventualmente cercare info nel changelog del nostro "pippo-current"
  
  
  Vediamo come si ptrebbe procedere nel caso non avessimo effettuato il backup dei file di configurazione modificati.
  In questo caso ci troveremo con i files:
  
  pippo.conf
  pippo.conf.new
  
  - per prima cosa si potrebbe escludere i file che ricadono nel caso 1.a (pippo.conf = pippo.conf.new) dovrebbe bastare un diff.
  - in teoria tutti i files diconfigurazione che riportano differenze ricadono o potrebbero ricadere nei 3 casi restanti e penso non ci siano altri stratagemmi semiautomatici per evitarci di controllare file per file ed eseguire le operazioni sopra, a seconda del caso in cui ricadono. Lascio come TODO a chi legge la descrizione di eventuali scorciatoie che la mia fantasia non arriva a partorire al momento.
  
  
  
  I.b- Passaggio alla versione successiva di slackware partendo da un sistema pulito e cercando di ricondurlo al nostro sistema attuale. In questo caso non abbiamo i file di configurazione nuovi targati .new.
  
  Se nella situazione precedente (I.a) potevamo limitarci ai file .new E .orig, adesso non abbiamo i files .new, ma se abbiamo gestito il sistema vecchio con raziocinio, dovremmo avere nel BACKUP del vecchio sistema i files .orig.
  Quindi se per esempio avessiomo il nostro pippo.conf.orig, basterebbe cercare sul nuovo sistema il nuovo file pippo.conf e confrontarlo col vecchio pippo.conf che avevamo modificato (proprio perchè è stato personalizzato, esiste il corrispondente .orig).
  In pratica per questa situazione I.b, i files .conf del nuovo sistema equivalgono "logicamente" ai files .new del caso I.a. Il punto è che solo avendo creato i .orig possiamo sapere cosa abbiamo modificato sul vecchio sistema...e possiamo di conseguenza limitarci a cercare sul nuovo sistema i corrispondenti files di configurazione.
  
  Ma se non abbiamo predisposto i .orig sul vecchio sistema è piuttosto dura trovare i files da modificare nel nuovo sistema.
  Questo perchè non possiamo restringere il campo ai files *.new che otteniamo nel caso dell'upgrade.
  Forse una strada potrebbe essere la seguente:
  
  • 1- effetuiamo il backup del vecchio sistema.
    2- procediamo all'upgrade del vecchio sistema ---> otteniamo i files .new ---> backup sistema aggiornato
    3- nella partizione dove si voleva mettere la nuova versione pulita, procediamo alla installazione (non upgrade)
    4- confrontando i punti (2) e (3), possiamo cercare sul sistema pulito i nuovi files di configurazione che corrisponderanno a quelli esistenti targati *.new che possono essere reperiti sul backup del sistema aggiornato.
    5- diff come sopra, ci aiuta ad escludere i files .new che cono identici ai files del backup del sistema vecchio (1).
    6- alla fine resteremo con tot files di configurazione che sono diversi da quelli della vecchia versione, per questi bisognerà procedere a mano, anche con l'aiuto di diff, ma in parecchi casi si tratterà di visonare il file, capire se la differenza è inputabile ad una nostra modifica del file vecchio, o ad un cambiamento nel file di configurazione nuovo rispetto all'originale vecchio. E di conseguenza editare il file nuovo, oppure lasciarlo intonso.
  Direi che per quanto riguarda i files di configurazione, lo snocciolo della questione finisce qui.

Per quanto riguarda i pacchetti, ho qualche dubbio circa il comportamento di upgradepkg, per cui prima di postare il pezzo "aggiornamento pacchetti" vorrei chiarirmi le idee su questo punto. Lascio pertanto così il presente post, magari chiedo in un prossimo messaggio meno ingombrante.
Nel frattempo dite pure, se cisonocorrezioni da fare aggiunte tagli ecc ecc.
A presto!

[conraid]

il primo metodo potrebbe essere una buonaintegrazione alle mie guide, perché adesso dico solo di controllare i file .new, mettere anche come fare a capire e modificare può essere utile
Anche se... chi aggiorna dovrebbe saperlo

me lo guardo meglio con calma e ti do le mie considerazioni

[ZeroUno]

Anche se... chi aggiorna dovrebbe saperlo

non è detto... non tutti gli slackwaristi sono guru. Soprattutto ora che per aggiornare non si usa più upgradepkg ma slackpkg

Ciao
01