Ciclo di vita di una guida, come aggiornare

[marcomg]

Magari è un argomento già trattato in passato, ma mi è sfuggito.
Come è bene comportarsi quando si rileva necessario l'aggiornamento di una guida?
Per esempio ho una vecchia guida con un software particolare che è compatibile con vecchie versioni di debian. Nella nuova cambiano delle cose.

Cosa è meglio fare

• ravano via tutto, rendo la guida compatibile con la nuova versione e perdo compatibilità con la vecchia (aggiorno il template)
• rendo la guida compatibile con entrambe le versioni specificando di volta in volta cosa è relativo a quale versione

Sarei in generale per la 2a opzione perché spesso vecchie versioni non si usano e le guide diventano illeggibili e veramente difficili da manutenere. Poi ovviamente un esempio di eccezione è questo https://guide.debianizzati.org/index.ph ... con_Debian dove ho aggiunto il supporto USB e non tolto quello per le porte seriali perché credo tutt'ora si utilizzino UPS seriali

Che ne dite?

[HAL 9000]

Non esistono vere e proprie linee guida, anche se la questione era già stata sollevata in passato, non ricordo più dove. Premetto che vado a memoria, provo a riportare quello che si era deciso allora, limitatamente ad alcune revisioni.

- Per guide passo-passo e molto dettagliate trattanti argomenti "da sistemista" (server, ecc...), può essere meglio creare una nuova guida, copiando integralmente quella precedente e modificando nella copia cosa è cambiato, aggiungendo poi dei link tra di loro (o in presenza di diverse guide ancor meglio con un menù verticale) e citando nel titolo della nuova guida il codename della versione di riferimento.
Sarebbe troppo confusionario dividere una guida già dettagliata in più sotto-sottosezioni in presenza di cambiamenti significativi e/o in più parti. E ci può essere interesse anche a distanza di tempo di consultare una guida per una versione passata. (Quanto passata? Non si era deciso, che io ricordi.)

- Per tutte le altre ha priorità l'ultima versione di Debian, cercando dove è possibile di dare informazioni utili - e verificate - anche per le altre. Mentre infatti sarebbe bello mantenere delle sezioni interne per ciascuna versione, se è possibile, di fatto non c'è sempre un modo semplice per chi verifica di appurare se le modifiche siano dovute al cambiamento di versione e non a una svista di uno degli autori. E poi, aggiungo io, siamo già pochi e non penso che siamo in grado di mantenere verificate informazioni perfino per le versioni passate per tutte le guide.
Forse ha senso solo per le guide trattanti il software base del sistema e la sua configurazione, e anche lì solo se si riesce a verificare effettivamente che le informazioni precedenti fossero corrette.
(Le versioni non più supportate, nemmeno via LTS, vengono comunque tolte dal template alla prima revisione.)

[marcomg]

era già stata sollevata in passato

Deve essermi sfuggita o devo averla dimenticata

sarebbe bello mantenere delle sezioni interne per ciascuna versione

Si è vero, magari o con le guide tipo Nomeguode/versione oppure proprio con un namespace, magari con il template versioni compatibili con i link ad ogni versione.
Sognare è gratis nemmeno avessimo personale stipendiato fisso a mantenere le guide sarebbe fattibile

può essere interesse anche a distanza di tempo di consultare una guida per una versione passata. (Quanto passata? Non si era deciso, che io ricordi.)

Diciamo che dopo un po' di versioni vecchie diventa accatonismo digitale. Vero che un archivio è sempre di interesse storico, ma trattandosi di guide non così tanto.
Per esempio su una lenny più che una guida su come installare apache è necessaria una guida su come aggiornarla o esportare i database per aggiornare (e magari litigare con APT sulle chiavi scadute). In realtà forse è una situazione più comune di quanto non dovrebbe essere, ma per dire che IMHO dopo un po' è giusto pensionarle, sono lì per confondere.
Vabbè si vede che sono combattuto, anche perché in verità non so cosa sia meglio.

Forse ha senso solo per le guide trattanti il software base del sistema e la sua configurazione, e anche lì solo se si riesce a verificare effettivamente che le informazioni precedenti fossero corrette.

Grazie, allora cercherò di stare attento e vedere di caso in caso.


Invece per quanto riguarda systemd. Meglio usare systemctrl o service? Perché service è retrocompatibile con sysvinit, ma systemctrl non credo.
Però sono abbastanza sicuro si andrà sempre più verso systemd e piano piano le resistenze verranno meno quando si capirà che gli sforzi extra non valgono la pena


Comunque grazie per le dritte

[HAL 9000]

Per esempio su una lenny più che una guida su come installare apache è necessaria una guida su come aggiornarla o esportare i database per aggiornare (e magari litigare con APT sulle chiavi scadute). In realtà forse è una situazione più comune di quanto non dovrebbe essere, ma per dire che IMHO dopo un po' è giusto pensionarle, sono lì per confondere.

Siamo pienamente d'accordo. Il difficile è trovare un giusto compromesso che vada bene a tutti.

Invece per quanto riguarda systemd. Meglio usare systemctrl o service? Perché service è retrocompatibile con sysvinit, ma systemctrl non credo

Avevo iniziato a usare "service" per via dell'annuncio di systemd, così che una guida possa essere compatibile sia per le versioni precedenti a systemd, sia per quelle successive.
Adesso però non fa molta differenza: ormai jessie è la oldoldstable (e quando sarà rilasciata bullseye, sarà forse supportata non ufficialmente dal team ELTS) e pure quella ha systemd. Quindi sarei per utilizzare direttamente systemctl da qui in poi. "service" ormai lo userei solo nelle guide più vecchie.

[marcomg]

Avevo iniziato a usare "service" per via dell'annuncio di systemd

Il problema è che spesso io proprio uso service per abitudine

sarei per utilizzare direttamente systemctrl da qui in poi. "service" ormai lo userei solo nelle guide più vecchie.

Per esempio questa guida https://guide.debianizzati.org/index.ph ... _pagespeed
Ho tolto un sacco di impostazioni che non erano più necessarie (perché di default). Inoltre secondo me si può proprio togliere il supporto per le vecchie versioni. Dubito che il pacchetto in questione sia ancora supportato per versioni così vecchie.
Già che ci sono smammerei anche /etc/init.d/apache2 restart oppure rimpiazzo entrambe con service.
(E devo pure aggiustare cite che lo ho usato malissimo).

[HAL 9000]

No, concordo di lasciare solo jessie (al massimo, o perfino stretch) e successive; e di usare systemctl ovunque. L'informazione altrimenti rischia di non essere nemmeno attendibile, specie in guide modificate diverse volte dalla data di stesura.

E se vuoi puoi usare anche "bullseye" se la stai già usando, visto che per l'anno di rilascio (stimato) si considera come "prossima stable" e non più testing, dopo i recenti aggiornamenti, in modo da portarsi un po' avanti con il lavoro di revisione.

[marcomg]

'informazione altrimenti rischia di non essere nemmeno attendibile, specie in guide modificate diverse volte dalla data di stesura.

Grazie del riscontro, appena ci rimetto mano (che devo riguardare i tempi verbali e fare coincidere quanto scritto da ferdy con quanto modificato da me) correggo.

puoi usare anche "bullseye" se la stai già usando

Ancora con bullseye non ho provato, ma dovrò farlo presto anche nell'ottica dell'update del server di debianizzati.

[HAL 9000]

Segnalo anche:
* net-tools deprecato in favore di iproute2
* [TASK #23] Revisione e fusione guide su iptables che dovrebbe invece occuparsi della migrazione a nftables (su cui al momento abbiamo una guida, ottima, di Wtf)

Per le altre guide da revisionare, cercherei di raggrupparle prima per argomento, in modo da occuparsi anche (se ce ne fosse bisogno) di fusione o integrazione con menù, per esempio:
* monitoraggio
* creare pacchetti deb e repository
* ambienti desktop minimali (hanno senso sotto-categorie specifiche, anziché una unica?)

Ho fatto qualche annotazione nelle discussioni del Wiki. Dopo la prossima settimana avrò più tempo per le revisioni vere e proprie, e per allora dovrei avere già tutti i sistemi con bullseye, così da verificarle direttamente per la prossima stable.

[marcomg]

Anche io settimana successiva (non la prossima, quella dopo ancora) dovrei riuscire ad essere un po'più presente
Grazie per il resoconto della situazione