Slackware 15rc2

[ZeroUno]

L'ultima volta che ho usato wayland ho avuto problemi con il dualscreen e con gli screenshot (sono tornato subito a xorg quindi non so se c'era anche altro)


Per quanto riguarda slackpkg+ okkio che non è LA soluzione a tutti i problemi, quindi usare con cautela. Particolare riguardo alle precedenze sui repository, e come è stato detto già finchè possibile installare il più possibile da un repository solo.
Nota che slackpkg+ come slackpkg non gestisce le dipendenze, nonostante alcuni repository le gestiscano (p.s. sono accettati suggerimenti; ho idea di lavorarci ma non ho tracciato la strada), e la maggior parte dei repository sono autoconsistenti a livello di dipendenze (non esiste che un pacchetto nel repository di slacky dipenda da un pacchetto nel repository di alienbob). slackpkg info pacchetto dovrebbe mostrare le dipendenze se dichiarate dall'autore.

slackpkg+ per current effettua la ricerca e download (non installazione) anche su sbo. Semplicemente riporta "è disponibile", dopodichè è consigliabile usare sbopkg per compilarlo ed installarlo.


Se invece si vuole solo sapere dove trovare i pacchetti va bene anche andare su slakfinder.org , senza dover installare nulla né farsi i giri su tutti i repository (su slackpkg+ è consigliabile censirne diciamo un paio di quelli fidati o usati più frequentemente; metterli tutti rischia di diventare più dannoso che utile a causa della eterogeneità)

[joe]

Libreoffice, dall'alto della mia ignoranza, la vedrei più come un'applicazione tranquilla, nel senso che probabilmente non va ad incastrarsi col resto del sistema in modo troppo complicato.
Un software come KDE invece è ben altra cosa, sempre ignorantemente immagino che KDE aspetti di trovarsi appoggiato su un certo substrato, ad esempio con un systemd che sta girando, o comunque con strumenti che sono presenti e attivi e che permettono all'ambiente desktop di comunicare con il resto del sistema.

E immagino anche che qui stia la difficoltà, nell'adattare l'ambiente desktop alla "tipicità" del sistema... chiamiamolo "core". Questo è forse il motivo per cui Pat ha qualche remora a "mollare" il mantenimento di KDE come pacchetto ufficiale gestito quasi direttamente da lui:
da un lato KDE è un progetto "di punta" tra gli ambienti Desktop, e per molti utenti può essere davvero utile averlo a disposizione sulla Slack, dall'altro se non fosse integrato a puntino, per quegli stessi utenti sarebbe un grosso problema che li metterebbe davanti alla scelta di passare ad altra distribuzione oppure utilizzare un ambiente desktop diverso e meno problematico perché più semplice (da Xfce in giù insomma). Gestire internamente l'integrazione di KDE consente a Pat di avere qualche garanzia in più che la ciambella esca col buco.
D'altra parte se la ciambella non esce mai più, di nuovo si pone il dubbio se restare con una vecchia slackware per anni, e anni... e anni!

Il tutto sempre che veramente il ritardo della nuova release sia dovuto a KDE.
Avevo letto opinioni più generiche al riguardo, del tipo che lo sviluppo del mondo linux negli ultimi anni ha accelerato parecchio e l'introduzione di novità è stata tale da mettere in difficoltà chi deve integrarle in un sistema finale stabile, cioè poi alla fine il rischio è di vedere uscire una release che dopo sei mesi è già vecchia rispetto a ciò che nel frattempo è apparso nel mondo linux. Certamente alcune innovazioni possono anche essere ignorate, ma poi se chi sviluppa software lo fa avendo in mente un sistema target che le preveda, quel software su slackware avrà problemi.

Come in tutte le cose complicate e che coinvolgono tante teste e tante idee, l'ottimo non esiste.
Esiste però il giusto mezzo probabilmente: un rinnovo annuale o biennale del sistema, anche se non perfettamente sincronizzato e integrato con le ultime diavolerie introdotte dalla tabella di marcia di distribuzioni più popolari e foraggiate, sarebbe ragionevole... magari non si avrà la slackware più stabile del mondo, ma d'altra parte si avrebbe la possibilità di avere accesso a software un po' più recenti senza troppi problemi e senza dover ricorrere a robe tipo flatpak o similari pachidermiche sovrastrutture.
Si potrebbe anche prevedere un ciclo tipo quello di un tempo del kernel: faccio uscire una "RC" unica oggi, e procedo ad un periodo di bugfix di sei mesi circa, senza sconvolgere la struttura del sistema. A quel punto faccio uscire la stabile vera e propria. In questi 6 mesi i manutentori terzi (AlienBob, SBo, ecc ecc) possono già procedere a creare pacchetti integrati col sistema RC, avendo la ragionevole garanzia che non ci saranno variazioni esagerate da lì al rilascio della stabile.
Quando viene rilasciata la stabile, tutto il software terzo che per sei mesi è stato pacchettizzato e testato, dovrà essere ri-testato e ci saranno alcune correzioni per avere una garanzia di buon funzionamento sulla stabile, ma dovrebbe essere un'operazione di fino e non un costruire da una tabula rasa...
Nel frattempo lo sviluppo ufficiale proseguirà dopo l'uscita della stabile sul solito ramo current, per circa un altro anno o anno e mezzo. Quando Pat ritiene congela tutto e rilascia la RC, che dopo 6 mesi porterà alla nuova stabile ecc...
Un ciclo del genere non è molto diverso da quello che accade ora, basterebbe solo qualche garanzia in più sulla tempistica.
Per capirci, la RC1 attuale è uscita ad agosto, per Natale non sarebbe stato male avere la nuova stabile, invece avremo una RC3 ben che vada!
Ovviamente il problema non è stato la fase RC, ma la fase Current post 14.2, questa avrebbe dovuto (ma non so se fosse possibile... diciamo che ci si sarebbe aspettato, via...) essere congelata un paio di anni fa. Magari ora staremmo attendendo la 15.0, stando al davanzale della intermedia 14.3 che non ha mai visto la luce.

[joe]

Se invece si vuole solo sapere dove trovare i pacchetti va bene anche andare su slakfinder.org , senza dover installare nulla né farsi i giri su tutti i repository (su slackpkg+ è consigliabile censirne diciamo un paio di quelli fidati o usati più frequentemente; metterli tutti rischia di diventare più dannoso che utile a causa della eterogeneità)

Sì anch'io faccio così qualche volta, quando no trovo né in official ne da Alien né su SBo.
Quando trovo un pacchetto terzo altrove, attraverso slakfinder, se non è un malloppo assurdo preferisco però compilarlo in locale. Un'operazione dovrebbe arginare almeno un po' l'effetto minestrone che dicevamo.

Sai cosa sarebbe utile in slackpkg+?
Poter limitare per N repositories la sola funzione di ricerca.

Ovvero: attivo solo il repo di alien ad esempio.
Ma posso cercare ugualmente anche su altri repo terzi. Attivati solo in lettura diciamo.
In questo modo non si dovrebbe per forza andare su slakfinder via web.
Non so se sia possibile integrare questa possibilità ma non sarebbe male.

[ZeroUno]

Intendi tipo che slackpkg search funzioni su tutti i repository ma che slackpkg install&co funzioni solo su determinati repository?
Questo significa che slackpkg update deve comunque scaricare un malloppo indicibile di metadata per poi non poterlo utilizzare.
Non vedo dove sia il problema ad inserire tutti i repository e metterli nell'ordine giusto e/o dare slackpkg install repo:pacchetto e/o verificare da quale repository sta tentando di installare e/o usare greylist sui repository che possiamo chiamare untrusted
personalmente in configurazione ho tipo
MIRRORPLUS['xxx']=.......
MIRRORPLUS['yyy']=.......
e in greylist
SLACKPKGPLUS_yyy

in questo modo se upgrade-all me lo prende da yyy non mi aggiorna il pacchetto a meno che non lo seleziono esplicitamente.


In alternativa una funzione che ho pensato a volte - ma che va fuori slackpkg - è un client cmdline per slakfinder (di cui avevo scritto delle api che ora credo siano obsolete). Su questo ho avuto un po' di remore a farlo a causa dell'impegno sulla manutenzione di slakfinder che richiede. Ma se ha richiesta potrei pensarlo.


Se invece intendi qualcos'altro rispiega.

[joe]

Hai capito bene, ed effettivamente slackpkg update sarebbe un "meta-problemone" che non avevo considerato.
Comunque era tanto per dire, alla fine anche andare su slakfinder e fare la ricerca, non è un problema dopotutto.
Forse come dici anche tu, la soluzione migliore per l'utente (non per chi deve mantenere lo strumento) potrebbe essere quella del client cmdline per slakfinder. Però appunto alla fine per quel che mi riguarda non è che installo e disinstallo tanta roba tutti i giorni e l'utilità nel mio caso sarebbe limitata a situazioni particolari e sporadiche... Quindi mi va già bene andare su slakfinder via web.
Slackpkg+ preferisco tenerlo più pulito possibile, non tanto perché non funzioni bene anche con greylist, ma perché comunque in ogni caso voglio evitare di installare da troppe fonti diverse per cui alla fine ho una configurazione più semplice in locale e alla bisogna posso sempre collegarmi a slakfinder.

[erio]

premessa: senza togliere nulla all'ottimo lavoro di zerouno nessuno ha mai usato slpkg,che si e' un pelino difficile ma puoi aggiungere o togliere come desideri penso che guardandolo bene gestisce anche le dipendenze ,nei limiti del possibile,e nell'ecosisrtema slackware credo sia molto utile...o sbaglio ps: io uso solo sbopkg e quando questo non crea i pacchetti uso i sorgenti,in questo slackware no ha eguali.

[joe]

Non conosco slpkg. mai usato. Dallo "screencast" sul sito sembra funzionare come si deve.
A proposito di dipendenze...

Codice: Seleziona tutto

sqg -p pippo
sbopkg -k -i  pippo

Il primo comando crea una "coda" di pacchetti che verranno compilati o comunque pacchettizzati dal secondo comando. Pacchetti che costituiscono le dipendenze presenti sul repository SBo per il pacchetto "pippo". L'opzione -k è utile quando non si volesse ricompilare un eventuale pacchetto della coda che magari abbiamo già installato sul sistema (occhio al discorso "minestrone").

Aggiungo che se questo sistema sembra un po' rigido in effetti è vero...
Però ricompilando ffmpeg partendo dallo slackbuild di SBo ho visto che puoi modificare lo slackbuild attivando vari funzionalità (tipo codecs e librerie varie che per ffmpeg possono servire).
Si può fare in vari modi, ma a me il più pratico sembra fare una copia dello slackbuild presente nell'albero del repo in /var/lib/sbopkg/SBo/14.2.
Nel caso di " ffmpeg4" ad esempio ho:

Codice: Seleziona tutto

# find /var/lib/sbopkg/ -iname "ffmpeg4*"
/var/lib/sbopkg/SBo/14.2/multimedia/ffmpeg4.tar.gz.asc
/var/lib/sbopkg/SBo/14.2/multimedia/ffmpeg4.tar.gz
/var/lib/sbopkg/SBo/14.2/multimedia/ffmpeg4
/var/lib/sbopkg/SBo/14.2/multimedia/ffmpeg4/ffmpeg4.SlackBuild
/var/lib/sbopkg/SBo/14.2/multimedia/ffmpeg4/ffmpeg4.info
/var/lib/sbopkg/SBo/14.2/multimedia/ffmpeg4/ffmpeg4.SlackBuild.sbopkg

La copia creata deve essere salvata con il suffisso ".sbopkg". In questo modo quando lanci "sbopkg -i ffmpeg4" ti chiede quale slackbuild vuoi usare, se quello ufficiale o quello presente in locale personalizzato. Certo è una buona cosa farne anche un'ulteriore copia di backup, perché se disgraziatamente eliminassi il repo locale, dovresti riscriverti le modifiche allo salckbuild ufficiale.

[erio]

se hai usato sqg per tutto il repository, lanciando in un terminale sbopkg e andando nella queue list trovi il pacchetto che cerchi piu' le dipendenze e trovi anche i pacchetti di quelle dipendenze che hai installato magari per altri software non devi per forza ricompilarli se sono di una versione aggiornata basta deselezionarli e salvo imprevisti compila e installa tutto.

[joe]

Solitamente uso sqg per singolo pacchetto, voglio provare però, per capire meglio cosa intendi...

[joe]

Ho provato... Ha impiegato un sacco di tempo.
Se lancio sbopkg senza argomenti si avvia l'interfaccia a menu testuale e posso ad esempio aprire la coda di qbittorrent.
Lì vedo la coda intera con le dipendenze che verranno elaborate nell'ordine:

Codice: Seleziona tutto

The following packages are currently in the queue. Please note
that when the queue is processed, the packages selected below will
be processed in the order listed from top to bottom.

Please select or unselect those packages you wish to keep in the   │
queue and then press <OK> to continue or press <Back> to go back.  │

[*] ninja                 Installed 1.10.2
[*] python3               New
[*] meson                 Installed 0.57.1
[*] libxkbcommon          New
[*] qt5                   New
[*] libtorrent-rasterbar  Installed 1.2.10
[*] qbittorrent           Installed 3.3.16

Però c'è un problemino...
Perché in realtà io qt5 l'ho installato dal pacchetto di Alien.

Codice: Seleziona tutto

# ls /var/log/packages/|grep qt5.*alien$
qt5-5.9.6-x86_64-1alien

Idem per "libxkbcommon", e anche python3.
In altre parole sbopkg non vede come presenti quei tre pacchetti già installati da una fonte differente rispetto a SBo.
Forse perché sono versioni più recenti su SBo rispetto a quelli installati.

Codice: Seleziona tutto

# sboversion qt5
5.12.8

sboversion è uno script che sputa fuori la versione di un pacchetto presente su SBo.
Probabilmente la spiegazione è che giustamente sbopkg ritiene come NEW il pacchetto visto che è più recente e di default ne eseguirebbe l'upgrade di quello installato.
Un report preliminare con anche il nome del pacchetto installato però non sarebbe male.

Non mi ero mai accorto di questa cosa, perché non uso così sbopkg, lo richiamo sempre da riga di comando.
Comunque non sono così sicuro che poi lanciando la coda con "sbopkg -k" si metta a compilare ugualmente qt5 pur trovandolo già installato sebbene di versione meno recente. O invece è proprio così?

[erio]

se usi la coda senza rimuovere la spunta da dove serve compila tutto quello che c'e',la differenza la fa se decidi di compilare e installare in automatico,ci sono software in cui devi per forza seguire la lista delle dipendenze e installarle seguendo l'ordine,penso che sbopkg non discrimina tra pacchetti diversi da sbo, avendo una current quella che uso e la versione sbo-git di ponce che rinnovo a ogni rilascio dei possibili upgrade.

[ponce]

Ho provato... Ha impiegato un sacco di tempo.
Se lancio sbopkg senza argomenti si avvia l'interfaccia a menu testuale e posso ad esempio aprire la coda di qbittorrent.
Lì vedo la coda intera con le dipendenze che verranno elaborate nell'ordine:

Codice: Seleziona tutto

The following packages are currently in the queue. Please note
that when the queue is processed, the packages selected below will
be processed in the order listed from top to bottom.

Please select or unselect those packages you wish to keep in the   │
queue and then press <OK> to continue or press <Back> to go back.  │

[*] ninja                 Installed 1.10.2
[*] python3               New
[*] meson                 Installed 0.57.1
[*] libxkbcommon          New
[*] qt5                   New
[*] libtorrent-rasterbar  Installed 1.2.10
[*] qbittorrent           Installed 3.3.16

Però c'è un problemino...
Perché in realtà io qt5 l'ho installato dal pacchetto di Alien.

Codice: Seleziona tutto

# ls /var/log/packages/|grep qt5.*alien$
qt5-5.9.6-x86_64-1alien

Idem per "libxkbcommon", e anche python3.
In altre parole sbopkg non vede come presenti quei tre pacchetti già installati da una fonte differente rispetto a SBo.

se ricordo bene non li vede perche' hanno un TAG (alien, in questo caso) diverso da quello del repository selezionato.

comunque, come sicuramente potrai gia' immaginare, non e' detto che gli script su SBo aggiornati per funzionare con qt-5.12.x funzionino anche con il 5.9.x... anzi, sono quasi certo che usare quel pacchetto precompilato da Alien ti creera' problemi nel compilare pacchetti da SBo che usano qt5.

[slucky]

Joe ha scritto:

Poi si sa, lo slacker ogni tanto deve anche un po' ravanare sotto il cofano... se no non è davvero contento e allora... c'è poco da fare

eh sì eh! se non smanettiamo non siamo soddisfatti...

[joe]

se ricordo bene non li vede perche' hanno un TAG (alien, in questo caso) diverso da quello del repository selezionato.

comunque, come sicuramente potrai gia' immaginare, non e' detto che gli script su SBo aggiornati per funzionare con qt-5.12.x funzionino anche con il 5.9.x... anzi, sono quasi certo che usare quel pacchetto precompilato da Alien ti creera' problemi nel compilare pacchetti da SBo che usano qt5.

Probabile, guarda, al momento ho una situazione temporanea che non gira proprio come un orologio, però funziona.
La maggior parte dei pacchetti SBo, li avevo compilati tempo fa, molto tempo fa. In pratica non ho un parco SBo installato sincronizzato con l'attuale situazione del repository remoto degli slackbuilds.
Nel caso di qt effettivamente potrebbero saltar fuori problemi. Ma solo se ricompilo roba che ha a che fare con qt5. Se lascio tutto com'è ora dovrebbe continuare a girare.
Ammetto di aver fatto un po' un minestrone anch'io e devo dire che sarebbe sicuramente meglio avere il più possibile da SBo.
Però sul mio vecchio PC compilare programmi grossi non è come dirlo, cioè è un'operazione lenta, invece prendere alcuni pacchetti da Alien, tipo libreoffice, belli e pronti alla fine riduce di brutto le tempistiche.
Ad ogni modo quello sopra è un esempio di un minestrone della serie "don't try this at home".
Per ancora una decina di giorni devo starmene col sistema così, funzionante. Dopo dovrei riuscire a metter mano ad un riordino. Del tipo che ho fatto l'upgrade un paio di settimane fa dei pacchetti ufficiali. Era tanto che non lo facevo e vi erano diversi aggiornamenti anche importanti tipo patch di sicurezza.

Ora per sicurezza vorrei ricompilare tutto il parco software SBo installato. In modo anche da escludere le incoerenze tipo quella di qt5 evidenziata sopra.
Sarà un'operazione un po' complicata e da fare un po' per volta immagino. La cosa da tenere in conto principalmente è generare la coda corretta con tutti i pacchetti da compilare nell'ordine giusto. Ne riparleremo più avanti magari, non chiedo consigli qui perché è OT e tanto ora non posso mettere in pratica nulla.
Potrebbe salvarmi solo l'uscita della 15.0, così invece di revisionare la 14.2, salvo il salvabile e faccio tabula rasa. Oppure aggiorno
Ma tanto non accadrà così a breve.

[hashbang]

Questo è il punto che mi ha sempre dissuaso dall'idea di utilizzare la current come rolling.

In che senso?

nel senso che se qualcosa va storto con un pacchetto (banalmente non è compatibile con un pacchetto che ti sei compilato tu, non necessariamente un bug di slackware) non hai modo di reinstallare il vecchio pacchetto.

Io ai tempi in cui usavo Slackware -current andavo di BTRFS proprio per questo.
Prima dell'upgrade, snap del subvolume che montavo in / e via. Se qualcosa va storto, rollback dalla snap e tutto tornava come prima.
Non avevo retention sulle snap; solitamente ripulivo tutto solo dopo l'uscita della stable, per poi riprendere.