Slackware: ne vogliamo parlare?

[Braccobaldo]

Rispetto al metodo che conosci per gestire il software quello del vademecum è tutta un'altra cosa. Mischiarli adesso potrebbe portarti a risultati imprevedibili. Ti consiglio di studiartelo con attenzione e di mettere da parte i metodi che conosci. Ripartendo da zero.
Tuttavia anche adesso puoi applicare quella guida dal principio fino a questo punto http://www.linuxminditalia.org/index.php?topic=22762.msg248502#msg248502. Ma ti ripeto: leggi tutto con attenzione.

[trigg]

ciao super-SuperCiuck
sono sicuro che prima o poi dovrò aggiornare il sistema ,per adesso mi limito santuariamente ma molto santuariamente ad aggiornarlo con gslapt per questioni di tempo .

non metto in dubbio nemmeno una delle tue parole e sai come sono fatto ormai  ;D vorrei solo capire e sapere di più :) , per questo precedentemente ho scritto quali sono le differenze tra slackpkg e gslapt  :roll:

dopo effettivamente non so se in realtà (considerando il mio inglese) con slackpkg alcuni software si corrompono , la mia è solo curiosità  :ciao:

[Braccobaldo]

...aggiornare con slackpkg è differente dall' usare gslpat selezionando il tasto mark all updates?

 


cosa cambia?

Per spiegarti in maniera comprensibile cosa cambia dovrei spiegarti prima quello che è scritto nel vademecum. Ed è per questo che l'ho scritto: per non doverlo spiegare di volta in volta...
Dopo di che dovrei tentare di spiegarti come funzionano slapt-get/gslapt (anche se credi di saperlo già...) e poi evidenziare le differenze.
Purtroppo tu, in gran parte per colpa mia, hai acquisito un modo di usare Slackware sregolato, che ti porterà prima o poi a situazioni che non saprai spiegarti ne gestire. Quello sarà il momento di studiarti quel vademecum e ripartire da zero.

...In modo particolare la prefazione. :)

:ciao:

P.S.
Se vuoi avere una idea di cosa può succedere se non gestisci i repo e gli aggiornamenti coscientemente (vale sempre, anche con gslapt...) leggi questo:

è assolutamente importante, direi fondamentale, che la scelta dei repo che useremo effettivamente sia oculata. L'errore che istintivamente commettono gli utenti poco esperti è quello di attivare più repository possibili, come se questo potesse garantirci i migliori risultati. Non è così. Anzi, direi piuttosto il contrario.
Se attivassimo troppi repo ci troveremmo ad ogni upgrade con un repo che vuole sostituire il software di un altro, che all'upgrade successivo sarà sostituito nuovamente dal primo o, ancora peggio, da un altro ancora. In un ciclo di vicendevoli sostituzioni assolutamente privo di senso. Questa situazione caotica è solo la parte più evidente del problema e la prima ad emergere. La parte peggiore, quella che sarà evidente solo dopo, è che creeremmo presto un gran casino con le dipendenze. Questo perché, anche trattandosi dello stesso software, nei diversi repository potrebbero essere richieste delle dipendenze diverse (anche solo leggermente) per alcuni pacchetti.
Se la situazione diventasse incoerente il software smetterebbe presto di funzionare lasciandoci con un sistema praticamente inutilizzabile se non nella sua configurazione originaria. Che tradotto significa che Slackware continua a funzionare ma il software che abbiamo installato invece no; ma con un po' di impegno si potrebbe mettere in difficoltà anche il sistema di base: usando, per esempio, senza cognizione, i repo di salixos e/o di connochaetos.

Con gslapt devi impostare correttamente le priorità dei repo, se vuoi avere una speranza...

[trigg]

adesso è chiaro il concetto
anche se ho paura di rovinare tutto il sistema che va davvero come mai è andato prima ,sbagliando il procedimento con slackpkg :

tornando a gslapt che con i suoi lilmiti mi rassicura , in che modo dovrei impostare i repo

 

se ho capito bene solo a 1 devo dare la priorità alta e quale delle sopra citate impostazioni da la precendeza ad un repo invece che all'altro.

[Braccobaldo]

... Così ti eserciti anche un po' con l'inglese:

DEFAULT    is the default, lowest priority
PREFERRED  assigns more weight to this source
OFFICIAL   even more weight, used to denote official sources
CUSTOM     highest priority, for your custom package source

http://software.jaos.org/git/slapt-get/plain/README

[Braccobaldo]

Avviso ai naviganti...

...Questa mattina ho fatto una nuova installazione di Slackware in aggiunta alla mia, l'ho aggiornata immediatamente e tra gli aggiornamenti c'era il kernel, che naturalmente ho aggiornato.
Siamo passati dall'originale 4.4.14 al 4.4.29 e oggi al 4.4.38.

A me è capitato che al riavvio lilo non è partito (lilo is big...). Se vi dovesse succedere sappiate che si rimedia facilmente.
Potete volendo escludere l'aggionamento del kernel da parte di slackpkg inserendo la "serie k" nella blacklist, prima di fare l'aggiornamento. Così:
slackpkg blacklist k

e accettate, dando invio, la selezione che vi propone.

EDIT: la procedura corretta per inserire il kernel nella blacklist di slackpkg è editare il file /etc/slackpkg/blacklist decommentando tutte le voci del kernel.

Codice Seleziona Espandi

#
# Automated upgrade of kernel packages aren't a good idea (and you need to
# run "lilo" after upgrade). If you think the same, uncomment the lines
# below
#
#kernel-firmware
#kernel-generic
#kernel-generic-smp
#kernel-headers
#kernel-huge
#kernel-huge-smp
#kernel-modules
#kernel-modules-smp
#kernel-source

... Leggi Qui

[bobol]

Credo sia meglio metterlo come post a sè, con titolo indicante proprio l'aggiornamento del kernel in modo da identificarlo meglio nelle ricerche  ;)

[Braccobaldo]

Ciao Bobol, non l'ho messo da solo perchè è un fenomeno occasionale e non volevo creare un allarme ufficiale. Inoltre, a quell'aspetto della ISO di installazione (recupero del sistema) volevo dedicare una discussione apposita. Vediamo come si evolve... ;)

Grazie!

[bobol]

 :ok:

[zar Marco]

Chiedo qui, così per curiosità, ma perché l'aggiornamento del Kernel è sconsigliato?

[Braccobaldo]

...Perché se un kernel funziona non c'è nessuna ragione di cambiarlo, almeno fino a che non sopraggiungono motivi validi...



EDIT: comunque, se il tuo riferimento è a questo post:

Notate sempre il suggerimento "saggio" che accompagna ogni configurazione:

Codice Seleziona Espandi

# Automated upgrade of kernel packages aren't a good idea (and you need to
# run "lilo" after upgrade). If you think the same, uncomment the lines
# below

Tradotto, letteralmente:

Codice Seleziona Espandi

L'upgrade automatico del kernel non è una buona idea (e avrai bisogno di eseguire lilo dopo l'upgrade).
Se tu la pensi allo stesso modo, decommenta le linee sotto.

#kernel-firmware
#kernel-generic
#kernel-generic-smp
#kernel-headers
#kernel-huge
#kernel-huge-smp
#kernel-modules
#kernel-modules-smp
#kernel-source

Il messaggio è: l'upgrade automatico è sconsigliato. Non l'aggiornamento del kernel in generale.

In sostanza, quando l'utente decide di cambiarlo lo cambia e basta. Solo è meglio non affidare il compito a un procedimento automatico.

[zar Marco]

Sì sì intendevo esattamente quello, grazie mille per la spiegazione

[Tony]

@zar Marco
Non citare i messaggi quando non ce n'è bisogno, come hai appena fatto.
Fallo solo quando, altrimenti, non si capirebbe a chi stai rispondendo.

[drugo]

@Super: alla fine ho dovuto dare il "comando magico" (per chi non si ricordasse lo può trovare nel Vademecum)  per ripristinare il SO allo stato originale  ;D
Nonostante ciò, non tutto il software funziona a dovere quindi mi sorge un dubbio:

è assolutamente importante, direi fondamentale, che la scelta dei repo che useremo effettivamente sia oculata. L'errore che istintivamente commettono gli utenti poco esperti è quello di attivare più repository possibili, come se questo potesse garantirci i migliori risultati. Non è così. Anzi, direi piuttosto il contrario.
Se attivassimo troppi repo ci troveremmo ad ogni upgrade con un repo che vuole sostituire il software di un altro, che all'upgrade successivo sarà sostituito nuovamente dal primo o, ancora peggio, da un altro ancora. In un ciclo di vicendevoli sostituzioni assolutamente privo di senso. Questa situazione caotica è solo la parte più evidente del problema e la prima ad emergere. La parte peggiore, quella che sarà evidente solo dopo, è che creeremmo presto un gran casino con le dipendenze. Questo perché, anche trattandosi dello stesso software, nei diversi repository potrebbero essere richieste delle dipendenze diverse (anche solo leggermente) per alcuni pacchetti.
Se la situazione diventasse incoerente il software smetterebbe presto di funzionare lasciandoci con un sistema praticamente inutilizzabile se non nella sua configurazione originaria. Che tradotto significa che Slackware continua a funzionare ma il software che abbiamo installato invece no;

Non è che per caso ho troppi repo: ho attivato quelli del Vademecum!
http://www.linuxminditalia.org/index.php?topic=22762.msg248739#msg248739

[Braccobaldo]

Slackpkgplus io lo tengo quasi sempre su off (prima voce del suo .conf)...
E lo uso solo per quei programmi che sarebbe lungo compilare: libreoffice e chromium (che sul repo di alien è piu aggionato).

E poi. Hai inserito SBo nella blacklist? ...

Se avete dato una occhiata al file /etc/slackpkg/blacklist vi sarete accorti che c'è un rigo, questo rigo:

Codice Seleziona Espandi

#[0-9]+_SBo

che basterà decommentare per inserire tutti pacchetti prodotti da sbopkg nella blacklist di slackpkg e suggellare l'autonomia dei due sistemi di gestione del software.

Scusa se sembro indiscreto, ma quali programmi non funzionano?...

...Perché se hai usato il comando magico hai pulito tutto il software terzo (ma se "sbo" stava nella lista nera i suoi pacchetti sono rimasti...), insomma, potresti essere un po' più dettagliato?