Newsgroup: it.comp.os.linux.iniziare
Titolo: Slack package manager: consigli, esperienze e considerazioni.

Salve a tutti, ho installato da poche settimane slackware 11.0. Non è la
mia prima distro...ho iniziato con fedora circa un anno e mezzo fà.
Premesso che ora come ora per installare un software scarico i pacchetti
tgz, di solito mi servo da 
slacky.eu
, visto che è presente anche una
descrizone delle dipendenze necessarie...
Di solito, quindi mi creo una directory col nome del pacchetto, in cui
edito un nuovo file contenente gli indirizzi dei tgz presenti su
slacky.eu
 o in altri siti (con unpo' d'attenzione...).
dopodichè mi sposto nella directory considerata e dò un bel 
"wget -i listapacchetti.txt" così scarica tutti i pacchetti necessari
nella directory di cui sopra.
A quel punto dò un "upgradepkg --install-new * " e di solito fila tutto
liscio oppure quando lanci l'eseguibile del programma, mi dà un errore
indicandomi gli eventuali pacchetti mancanti...facilmente reperibili ed
installabili nella maggior parte dei casi.
Questo procedimento non mi dispiace, ma il copia ed incolla degli
indirizzi nella lista dei pacchettida scaricare mi fà perdere un po'
tempo, visto che devo andare a ricercare il pacchetto a mano e  non ho
linea veloce.
Così ho deciso di capirci di più riguardo ai package manager
utilizzabili in slackware:
su S4d (ho dato una letta veloce..), pare che i progetti più
interessanti e maturi siano swaret e slapt-get.
Poi ne elenca altri tipo emerde (oops  ;-) ) e altri ancora.
Mi piacerebbe avere qualche info sulla convenienza di utilizzare un
gestore del genere. Eventualmente quale usereste e pssibilmente perchè.
Magari descrivendone anche i limiti e problemi di pasticci eventuali.
Se ne avete utilizzati più di uno e volete spiegarne brevemente le
differenze e comparare l'uno all'altro...ben venga.
Vi ringraio in anticipo e vi saluto. A presto  :-)

interessanti e maturi siano swaret e slapt-get.
Non ne conosco nessuno, ma se slapt-get e' apt-get della
Debian non avrei dubbi: non fa MAI un solo errore, e'
veramente incredibile e secondo me non e' fatto da umani.
Anzi: dopo i commenti che ti faranno me lo provo.
-- 
Saluti, Dalet

JohnnyNewbie wrote:
IHMO swaret e' ottimo ma e' "vecchio" chi lo ha scritto non l'ha piu
aggiornato da parecchio , quindi va usato con attenzione .
slapt-get + gslapt non sono male , rimane slackpkg, e' quello di default ,
ottimo anche quello , provali tutti e poi scegli .
-- 
2.6.21.3

 ottimo anche quello , provali tutti e poi scegli .
ma se non sbaglio, slackpkg non gestisce le dipendenze, al contrario di
slapt-get, giusto?
-- 
"Chiamo cristianesimo la sola grande maledizione, la sola enorme
perversione interiore: il solo grande istinto di rivincita per il
quale nessun mezzo e' troppo velenoso, clandestino, sotterraneo e
meschino. Lo chiamo macchia immortale dell'umanita'." (F. Nietzsche)

 veramente incredibile e secondo me non e' fatto da umani.
Non ha nulla a che fare con apt , lo stesso apt che su debian e  derivate
riesco ad incasinare perfettamente , il problema non e' apt , sono io ...
(questo e' uno dei motivi per cui preferisco Slack a Debian) 
slapt-get non ha di questi problemi (e' molto meno complesso) .
-- 
2.6.21.3

JohnnyNewbie wrote:

Scusa ma quello di default e' installpkg e removepkg che a
mio giudizio e' il migliore in assoluto forse anche dello
stesso apt-get di Debian per semplicita' e senza considerare
che apt-get va in rete da solo e ti installa/propone anche
tutti i pacchetti collegati.
Solo che funziona soltanto coi pacchetti gia' fatti.
A JohnnyNewbie direi: leggiti l'essential, cioe' lo
Slackware-book sulla gestione dei pacchetti, cioe'
i programmi:
installpkg
removepkg
explodepkg
magari anche solo dando "man installpkg".
-- 
Saluti, Dalet

 Scusa ma quello di default e' installpkg e removepkg
Stai facendo confusione , i pkgtools (installpkg,removepkg,etc,etc) sono lo
strumento per installare,rimuovere,upgradare in locale , se vuoi uno
stumento simile ad apt per gli aggiornamenti da rete devi usare slackpkg
e /o gli altri tools menzionati .
se lanci pkgtool --->View -----> pkgtools vedrai cosa ne fa parte .
-- 
2.6.21.3

 utilizzabili in slackware:
mah, io li evito, come Brainless sono capace di incasinare persino apt 
su Debian, ma capisco che può dipendere dal fatto che ho un'adsl flat;
non saprei, se ti diranno che slapt o swaret sono a posto direi che 
potresti provare -in fondo se non erro puoi mettere solo il repository 
slacky che mi sembra il più affidabile, oltrte a quelo ufficiale che 
sempre roba IT è;
r
-- 
E allora, 'sto miracolo?
[Forzuto Italiota, impaziente]
Baudelaire e l'arte: 
http://umpf.net/

Stai facendo confusione , i pkgtools (installpkg,removepkg,etc,etc) sono lo
[...]
Gia'... capit :-)
-- 
Saluti, Dalet


Bene, visto che slackpkg è quello di default, partirò da quello.
Le dipendenze non le gestisce, quindi occorrerà un po' di tempo in più
per portare a termine ò'installazzione di un pacchetto...ma non
dovrebbero esserci grossi problemi.
Swaret, mi pareva di aver capito che fosse la cosa migliore per la
slack, ma se il progetto non è molto aggiornato e occorre attenzione,
allora lo proverò in seguito....visto che sono un po' alle prime armi,
non so di preciso a cosa devo porre la particolare attenzione....
Di Slapt-get, ho letto che per soddisfare le dipendenze si basa sulla
presenza nel pacchetto tgz in questione di un file che elenca i
pacchetti di dipendenza, ora, poichè i pacchetti slackware non hanno di
per se lo standard di includere questo file, potrebbe essere che in certi
casi le dipendenze non siano soddisfatte correttamente...
Almeno questo grosso modo è quello che ho capito io...
ho sentito anche dell'uso di rsync ma imlicherebbe la creazione in
locale di un mirror al repository ufficiale (o non..), se non ho
capito male...
Questo fatto comporterebbe troppo utilizzo di HD per i miei gusti. E
anche troppa banda per l'aggiornamento del mirror.
di emerde non ho avuto risposte, probabilmente perchè non è molto usato
o non è molto efficente...boo...
Vi ringrazio per le risposte ottenute e se volete aggiungere altri
aspetti che vi pare non abbia compreso o altri commenti generici, non
esitate.
A presto! :-)

 mia prima distro...ho iniziato con fedora circa un anno e mezzo fà.
[CUT]
Ti rispondo da utente Slackware da alcuni anni. All'inizio la mancata 
verifica delle dipendenze genera sconforto, ma mi sono convinto che e' 
un male sostanzialmente minore. Ovviamente, Slackware non e' la 
distribuzione che si installa in dieci minuti e non tocchi piu' niente.
Uso a volte slapt-get, ma non busigna illudersi: non esiste un 
repository universale per Slackware, a volte trovi i pacchetti su 
Slacky.eu, a volte su 
linuxpackages.net
, altre volte sparsi qua e la'. 
Senza contare che i pacchetti di Slacky.eu si sovrappongono a quelli 
della release ufficiale, ma con nomi diversi. Quindi potresti trovarti 
due installazioni della stessa applicazione.
Se cerchi un sistema di gestione dei pacchetti che faccia tutto da solo, 
su Slackware non esiste. Esistono soluzioni parziali, e certe volte e' 
piu' conveniente la compilazione dei sorgenti.

 piu' conveniente la compilazione dei sorgenti.
Bè la compilazione da sorgenti non mi dispiace, sempre che il buon
checkinstall funzioni bene (e sulla slack, per ora non ha dato
problemi). Cioè compilare i sorgenti va bene, ma poi vorrei poter
gestire tutto con i pkgtool, pertanto dovrei pacchettizzare ciò che è
stato compilato e per me non è un'operazione facilissima...dovrei
documentermi un po' e mi occorrerebbe forse più esperienza...per questo
checkinstall se funziona è un toccasana.
Insomma per ora mi sto documentando su slackpkg, che pur non facendo
tutto, mi eviterebbe di navigare tra svariate pagine web per scaricare i
pacchetti necessari.
I dubbi maggiori sono l'impostazione del mirror migliore e la eventuale
sovrapposizione di installazione con pacchetti di 
slacky.eu
 o altri
repo.
Se voleste descrivere come impostate i repo in slackpkg e come
affrontate l'inghippo delle sovrapposizoni, mi chiarireste ulteriormente
le idee.  :-)
Vi ringrazio per la disponibilità, sperando che la discussione sia di
utilità anche ad altri che si avvicinano a questa distro. ;-)
A presto  :-)

 checkinstall se funziona č un toccasana.
fatti uno script che tenga traccia di quello che installi dai src ...
cosi' almeno puoi usare removepkg per "pulire" l'installazione ...
poi ti fai uno script config in cui imposti una volta per tutte le opzioni
per il './configure' di un dato programma, cosi' per aggiornare non devi
fare ogni volta './configure --help|less' ...
io faccio cosi' da anni, e mi trovo benissimo ...
ciao ...
-- 
#include <stdio.h>
int main(void){char c[]={10,65,110,116,111,110,105,111,32,98,97,114,98,111,110,
101,32,60,104,105,110,100,101,109,105,116,64,116,105,115,99,97,108,105,110,101,
116,46,105,116,62,10,10,0};printf("%s",c);return 0;}

 ciao ...
Saluti e grazie ancora!  :-)

 capire che lasituazione forse è differente...
per uscire dall'ot, mandami una mail all'indirizzo:
straicher (at) tiscali (dot) it
e ti mando i due script che uso ... ovviamente sono un esempio configurato
per le mie esigenze, ma puoi prendere spunto ...


Rinnovo l'invito:
Oltre al man d slackpkg esiste un how-to, una guida o qualsiasi cosa un
po' più "informale" con consigli su quale mirror scegliere? e magari
perchè?
Da quello che ho capito funziona solo con pacchetti ufficiali, quindi se
volessi scaricare da 
slacky.eu
, per esempio, non potrei fare niente con
il buon slackpkg, giusto?
Visto che vorrei non combinare pasticci, avendoinstallato la 11.0, devo
settare la versione a 11.0, non a current vero?

Allora: ho seguito questa guida:
http://www.slackbasics.org/html/pkgmgmt.html
in inglese ma direi abbaztanza semlice...
ho dato "slackware update" e poi mi sono detto: installiamo  rtorrent,
tanto per fare fare una prova.....
Bene, rtorrent non c'è proprio nei repo ufficiali?
Slackpkg non l'ha trovvato, mentre ha trovato facilmente tante voci col
pattern "torrent". :-(
Gli amici di 
slacky.eu
, invece conservano tra i loro pacchetti sia
rtorrent che le sue dipendenze...però devo tornare a navigare il loro
sito con firefox (o links per far prima).
Sto slackpkg non ha iniziato bene la sua carriera, comunque è presto per
giudicare (chiaro che il problema è del repo ufficiale, un po' sguarnito
forse...).
A presto :-)

 
Di solito, con slackware non si trovano i pacchetti in un unico 
repository. Inoltre, a differenza di Debian, esistono solo alcuni 
pacchetti precompilati da volenterosi. Altrimenti, bisogna compilarsi i 
sorgenti a tanti saluti.

 sorgenti a tanti saluti.
questo era vero anni fa, al momento non ricordo di aver avuto la 
necessità di compilare qlc dall'ottobre scorso, quando ho messo su la 11;
solo amule, ma nella versione cvs, quindi l'avrei dovuto fare con qls 
distro;
r
-- 
The seven is the number of the young light
it forms when darkness is increased by one
[Syd Barrett]
Ramapage: 
http://umpf.net/

 
Peccato...
A me andava benissomo slackpkg (almeno...penso), nelle occasioni in cui
devo fare in fretta...
Comunque, sarà sicuramente valido per soddisfare dipendenze di librerie
più terra terra (tipo scarico un pacchetto da 
slacky.eu
 e po ne soddisfo
le dipendenze ovviamente a mano, ma senza andarmele a cercare navigando,
bensì dando "slackpkg install dipendenza").
Insomma non è il massimo, ma fa già risparmiare tempo a chi come me non
ha adsl.
Che sappite esiste un metodo per sapere a priori quale siano le
dipendenze di un certo pacchetto?
Da qualche parte ho letto di ldd...chiaramente non ho letto il man e lo
farò non appena ho un attimo. Ma così in termini generali come si può
fare senza essere esperti? (chiaramente a priori...altrimenti lanciando
il programma logicamente dice cosa manca...).
A proposito come mirror ho messo eutelia...cosa ne dite?
ce ne sono di migliori secondo voi?
Se mai fate un fischio  8-D
Come al solito ogni commento è utile per chiarire la situazione.
Saluti


Riconosco che la maggior parte delle volte basta cercare bene e il
pacchetto salta fuori. Personalmente attingo a piene mani da 
slacky.eu
per le applicazioni desktop, mentre per quelle server preferisco
compilare da me (postfix, courier-imap, ecc)

 Come al solito ogni commento è utile per chiarire la situazione.
mi rincuori, in pratica non ti ho detto niente che già non sapessi;
r
-- 
Occidente Occidente
alla guerra alla gloria alla storia
[da Ko de mondo, CSI 1994]
tutto sui Pentangle: 
http://umpf.net/

 mi rincuori, in pratica non ti ho detto niente che già non sapessi;
Non c'è problema, fa sempre picere fare due chiacchere!!!  :-D

 rischierei senzaltro di pasticciare:
Scusa se mi intrometto ma avrei una domanda:
mi spieghi meglio cosa intendi quando parli di "Slackware" e "dipendenze" ?
Puoi farmi qualche esempio ?
Tnk's
Rizio

 Puoi farmi qualche esempio ?
ehm, in che senso?
Per slackware intendo la omonima distribuzione gnu/linux.
Per dipendenze....bè un certo software per funzionare ha bisogno che sul
sistema siano presenti ed installati altri programmi dai quali esso
dipende.
Quindi se il software "pippo" dipende da "topolino" e "paperino" allora
per farlo funzionare dovrò installare sia pippo che pluto e paperino,
altrimenti pippo non funzionerà.
Un package manager tipo apt-get della Debian (un'altra disto gnu/linux)
esegue le seguenti operazioni (per esempio se voglio installare pippo):
do il comando "apt-get install pippo"
apt-get accede ad un repository in rete e preleva il pacchetto pippo.deb
inoltre, visto che ipacchetti deb contengono come standard la lista di
software di dipendenza (nel nostro caso pippo.deb contiene anche una
lista in cui c'è specificato che occorrono anche paperino e topolino,
installati sul sistema...qualcosa del genere insomma), allora apt-get
verifica la presenza sulla macchina di paperino e topolino e nel caso
siano assenti, preleva anche loro dal repository e installa tutto.
In tal modo col solo comando "apt-get install pippo" ti ritrovi
installato pippo e tutte le sue dipendenze, in modo da avere tutto
funzionante. Poichè e tutto automatico risparmi un po' di tempo e se
vuoi fare in fretta è un ottimo sistema.
La slackware invece non lavora coi pacchetti .deb, ma coi propri
pacchetti .tgz che non prevedono come standard la presenza di una lista
delle dipendenze da soddisfare, se vuoi installare pippo lo puoi
installare, ma per farlo funzionare dovrai installare anche paperino e
topolino a mano... questo è lo stile originario della slack e il buon
Patrick (colui che l'ha creata e la mantiene), non ha predisposto alcun
tool di default per la gestione, diciamo automatica, delle dipendenze.
Questo non è un grosso problema, se non si ha fretta...
In pratica hai diverse strade, diciamo ufficiali per installare pippo:
accedi ad un repository a mano (col tuo web browser o altro), scarichi
pippo.tgz, lo lanci e lui ti avverte che per funzionare manca paperino.
Allora accedi di nuovo alrepository cerchi paperino.tgz lo scarichi e lo
installi e riprovi a lanciare pippo il quale ti avvertirà che manca
topolino. Quindi accedi ancora al repository cerchi sacarichi e installi
topolino.tgz e quindi rilanci pippo..ora dovrebbe funzionare.
Se pensi di fare tutto ciò con un connessione poco veloce la storia
diventa un po' scomoda quando hai fretta (se non hai fretta invece è
quanto mai divertente ;-) ).
Ora anche in slack esistono dei package manager tra cui swaret e
slapt-get i quali grosso modo fanno il mestiere di apt-get.
Ma in slackware i repo con più software non son ufficiali e non è
mantenuto tutto come su Debian (questo perchè la filosofia slack è
differente...). Quindi l'automatizzazione della risoluzione delle
dipendenze a volte fa cilecca o rischia di fare pasticci.
Penso che finchè la questione non sia presa in considerazione da Patrick
questo problema sarà sempre più o meno presente...
Poi c'è un software di nome slackpkg che pur non risolvendo le
dipendenze è in grado di accedere al repository ufficiale e scaricare ed
installare il pacchetto che hai richiesto:
slackpkg install pippo (o qualcosa del genere...l'ho usato solo una
volta...), e lui accede al repository ufficiale scarica e installa
pippo.
lanci pippo e ti avverte che mancano paerino e topolino quindi dai
"slackpkg install paerino" e "slackpkg install topolino" e se non manca
altro sei apposto.
Non risolve le dipendenze automaticamente, ma fa comunque risparmiare
tempo. Il problema è che accede solo al repo ufficiale di slackware che
è un po' sguarnito e quindi se non c'è pippo nel repo lo dovrai
scaricare da un altro repo non ufficiale...chiaramente a mano ;-)
L'ho fatta lunga, ma spero di aver esaurito i dubbi.
Non ètutto preciso ma dovrebbe rendere l'idea di massima della
situazione così come l'ho capita io.

 altrimenti pippo non funzionerà.
[CUT]
Osserva pero' anche i lati positivi. Debian specifica delle dipendenze
che spesse volte sono sovrabbondanti o restrittive, e poi e' piu'
complicato scegliere un'altra strada. Esempio: volevo togliere tetex e
mettere texlive 2007. Avevo gia' l'iso ufficiale di quest'ultima release
e pensavo di fare sotto Etch come sotto Slackware. Tutto a posto, solo
che quando ho cercato di rimuovere tetex, apt-get ha preteso di rimuovere
una dozzina di dipendenze, fra cui kile, auctex, ecc. Auctex l'ho
installato dopo senza problemi, ma il pacchetto di kile pretende tetex
o texlive 2005. In rete ho trovato una soluzione che ritengo macchinosa:
la creazione di un pacchetto finto che inganni apt-get. Per mia fortuna,
c'e' uno sviluppatore Debian che aggiorna i pacchetti di texlive 2007 per
etch, e grazie al suo repository ho evitato strani imbrogli.
Quindi, tutto automatico significa anche tuto meno flessibile. Te ne
accorgi raramente, ma in quelle rare volte passi le mezz'ore a cercare
vie d'uscita.

 situazione cosě come l'ho capita io.
Con la spiegazione sei stato davvero esaustivo, veramente ottima.
Mi dispiace solo aver posto male la domanda perche' io intendevo proprio 
un esempio pratico perche' non mi e' ancora capitato di dover scaricare 
dei pacchetti per far funzionare degli altri... magari vuoi "estendere" 
le funzionalita' del primo (es. mod_ssh per apache) ma il software di 
per se funziona gia' cosi' come l'hai scaricato.
Volevo capire perche' parlavi di dipendenze su slack
P.S. Il mio discorso e' riferito ai pacchetti "ufficiali" scaricati per 
la stessa piattaforma che hai installato.

o texlive 2005.
Mi sembra che dovresti aver capito male... guarda:
# dpkg --no-act --purge tetex-bin
======================================
dpkg: problemi con le dipendenze impediscono la rimozione di tetex-bin:
 kile dipende da tetex-bin | texlive-base-bin; comunque:
  Il pacchetto tetex-bin sta per essere rimosso.
  Il pacchetto texlive-base-bin non è installato.
 tetex-extra dipende da tetex-bin (>= 2.99).
 preview-latex-style dipende da tetex-bin | texlive-base; comunque:
  Il pacchetto tetex-bin sta per essere rimosso.
  Il pacchetto texlive-base non è installato.
dpkg: errore processando tetex-bin (--purge):
 problemi con le dipendenze - rimozione non effettuata
================================================
Cioe' mi sa che, se non te l'ha fatto apt, ti basta fartelo
da te un link a texlive-base-bin.
Dselect infatti NON propone la rimozione obbligata di kile,
ma dice: "raccomanda" tetex, quando ho simulato l'
installazione di texlive.
E anche apt-get, invece di dare dpkg direttamente, NON dice
che rimuove kile, guarda:
# apt-get --no-act install texlive | grep kile
===============================================
Remv tetex-bin [3.0-30] [preview-latex-style latex-beamer latex-xcolor kile]
Remv tetex-base [3.0.dfsg.3-5] [preview-latex-style pgf latex-beamer
latex-xcolor kile]
Remv tetex-doc [3.0.dfsg.3-5] [preview-latex-style pgf latex-beamer
latex-xcolor kile ]
Inst texlive-common (2005.dfsg.3-1 Debian GNU/Linux 4.0 r0 _Etch_ - Official
i386 DVD Binary-1 20070407-11:40) [preview-latex-style pgf latex-beamer
latex-xcolor kile ]
Inst texlive-doc-base (2005.dfsg.2-1 Debian GNU/Linux 4.0 r0 _Etch_ -
Official i386 DVD Binary-1 20070407-11:40) [preview-latex-style pgf
latex-beamer latex-xcolor kile ]
===================================
-- 
Saluti, Dalet

 la stessa piattaforma che hai installato.
Ah be` questo sinceramente non so se comporti delle migliorie dal punto
di vista delle dipendenze, spiegati un attimo meglio se puoi...poi
dipende anche quali pacchetti hai compreso all'atto dell'installazione
della slack. Se hai un installazione full presumibilmente avrai meno
software da dover installare...chiaramente.
Saluti  :-)

 vie d'uscita.
Quoto. Infatti per questo sono convinto che e` meglio che sulla slack le
dipendenze si risolvano a mano. Certo che un gestore come slackpkg
capace di accedere anche ad altri repo non mi dispiacerebbe. Sarebbe
solo un utilita' piu` comoda per accedere e scaricare dal repo, nonche`
installare, aggiornare etc. MA non risolvere le dipendenze cosa
abbastanza rapida comunque sfruttando un gestore del genere.
Anche se forse mescolare repositries ufficiali e non tipo 
slacky.eu
 o
linuxpackages.org
, forse creerebbe qualche problemino di
sovrapposizioni... e qui viene fuori il problema forse di una mancanza
di pacchetti nei repo ufficiali...


Ti chiedo scusa, ma mi sono perso. QUal e' la morale del tuo post?
che per installare kile e texlive 2007 mi basta ingannare il sistema
con un link simbolico?

Il 06-06-2007, Simone dice:



No.. ho interpretato male io la pipe, indica semplicemente che
kile dipende indifferentemente da tetex-bin o da texlive-base-bin
(e' la sintassi del tipo: [a|b|c] cioe' uno qualsiasi di a,b,c).
Dunque non dovrebbe essere da rimuovere, ne' dovrebbe aver
bisogno di link o altri accorgimenti o finti pacchetti.
-- 
Saluti, Dalet

 software da dover installare...chiaramente.
Come ti dicevo prima si fa fatica a parlare di dipendenze con 
slackware... un conto e' se chi distribuisce il sw "presuppone" che tu 
abbia gia' altre librerie, un altro e' se tu ti scarichi i sorgenti con 
tutto quello che gli serve e compili tutto ex novo.... dai un'occhiata a 
gentoo ;)
Cmq, no problem... era solo per capire.
Bye
Rizio

 Rizio
è stato un piacere! :-)

 invasiva, mi fido più dei compari di 
slacky.eu
.
be', finora non ho avuto noie con i suoi pacchetti, mentre ricordo 
vagamente di averne avuti con quelli di linuxpackages, ma non gravi e 
risalenti a tempo fa;
r
-- 
Se le macchine pensano? Io sono una macchina e so pensare.
[Marvin Minsky]


 risalenti a tempo fa;
Confermo anch'io che slacky cosi` a naso mi sembra piu` affidabile.
Saluti, mi piacciono queste discussioni :-)

 bel po' di software open, non vi pare?
velocizzerebbe un poco  la ricerca dei pacchetti ma si sprecherebbe un 
bel po' di tempo a compilarli;
cmq quello che ti serve veramente a quanto ho capito è un metodo veloce 
e automatico per scovare i .tgz, non credo che un programmino per farlo 
sia molto complicato da realizzare, non c'è qlc programmatore nel ng? 
forse basterebbe un semplice script;
volendo si potrebbe aggiungere anche il resto, così che dopo aver 
mostrato i pacchetti che ha trovato (e dove) chieda quale pacchetto 
scaricare e installare;
r
-- 
verrà la Parusia come ladro di notte
Baudelaire e l'arte: 
http://umpf.net/

 
Il mio problema era la mancanza di texlive 2007 sui repository della 
stable. C'era solo texlive 2005, ormai obsoleta. Purtroppo 
l'installazione manuale di texlive non riesce a convincere il sistema di 
dipendenze di Debian che e' tutto a posto, dato che installa in 
/usr/local/TeXlive/2007 e non crea nessun link simbolico.
Chiaramente potevo installare kile con dpkg, ma a quel punto apt-get 
lamentava la presenza di dipendenze non soddisfatte.

 scaricare e installare;
bč si questo dovrei essere in grado di farlo piů o meno, non ci giurerei
ma con un po' di documentazione...
Bel consiglio grazie! :-)
Arrisentirci



Non so perche` ma mi ricorda qualcosa...
http://groups.google.it/group/it.comp.os.linux.iniziare/browse_frm/thread/8492eebc7add2e64/dcfbe68fd77ddcae
Almeno impara a smettere di incolpare degli strumenti, non e` colpa loro se non sai usarli.

 bo...
potrebbe scaricare (se necessario) PACKAGES.TXT  e cercare lì;
fra l'altro sono segnate le dipendenze ed eventuali conflitti:
PACKAGE REQUIRED:  glibc-solibs >= 2.3.6-i486-6,ncurses >= 
5.5-i486-1,readline >= 5.1-i486-1
quindi si potrebbe complicare lo script in modo che controlli se sono 
soddisfatte e nel caso le segnali  e/o cerchi di scaricarle;
  ma mi sa che a furia di aggiunte diverrebbe un altro swaret ;-P
r
-- 
Dites, qu'avez-vous vu?
[Fleurs du mal, CXXVI]


 Almeno impara a smettere di incolpare degli strumenti, non e` colpa loro se non sai usarli.
Chi ha mai detto che so usarli? E poi e' piu' noioso imparare tutte le 
opzioni di dpkg che farne a meno nelle situazioni meno banali.
Dico solo che nella mia personale esperienza preferisco usare pochi 
strumenti automatici.
Nel caso in questione, c'e' modo di mettere tutto a posto, ma
preferisco aggiungere quello che serve piuttosto che togliere quello che 
non serve. Tutti i sistemi di gestione delle dipendenze sono 
sovrabbondanti, e appena posso li evito. Anche su Debian compilo i 
sorgenti togliendo le opzioni che non mi servono. Per dirla tutta, cosa 
importa allo sviluppatore se c'e' un sistema TeX? Tu installa kile, e 
poi ci pensa l'utente a metterci il sistema TeX che preferisce.

lamentava la presenza di dipendenze non soddisfatte.
Ora ho copito, e non avevo notato il 2007.
Chiaramente nel pacchetto .deb della 2005 c'e' l'struzione
per le necessita' di kile (e degli altri +o- dipendenti),
istruzioni che ovviamente nel .src non ci sono.
Beh io nel caso installo la 2005, perche' per la 2007 si
dovrebbe prima fare il pacchetto .deb e non ne sono capace. 
-- 
Saluti, Dalet

  ma mi sa che a furia di aggiunte diverrebbe un altro swaret ;-P
Sì...meglio lasciare perdere le dipendenze per il momento seguiamo la
filosofia KISS (non è rivolta a te...chiaramente  ;-) ).
Direi che si potrebbe separare il download di quel file in modo da
scaricarlo una volta per tutte, senza doverlo riscaricare ad ogni
richiamo dello script:
qualcosa tipo?
"vuoi aggiornare la lista dei pacchetti diponibili su 
slacky.eu
?"
e l'utente risponde si o no.. nel caso la risposta sia no si utilizzerà
lo stesso file precedentemente scaricato...
oppure si potrebbe impostare un paramtero allo script tipo -updaterepo
da richiamare al lancio dello script.
In entrambi i casi è meglio scaricare il file PACKAGE.TXT.gz per
risparmiare banda e quindi tempo dopodichè scompattarlo con gunzip.
Il mio problema è estrapolare dal file il link al tgz da passare a wget:
con grep è facile trovare la riga contenete l'indirizzo ad esempio per 
rtorrent una volta che ho in locale il PACKAGES.TXT basta dare:
grep LOCATION PACKAGES.TXT |grep -i rtorrent
e lui restituisce:
PACKAGE LOCATION:  ./utilities/rtorrent/0.7.4
Ora dovrei riuscire a estrapolare solo l'indirizzo:
"/ulilities/rtorrent/0.7.4" e assegnarlo ad una variabile che potrebbe
essere chiamata LINK, per esempio.
in modo da utilizzare il sucessivo comando:
wget -P $tmptgzslacky "
http://www.slacky.eu/repository/slackware-11.0
"$LINK
A quel punto si avrebbe a disposizione nella directory $tgzslackydir,
che potrebbe essere una dir temporanea in cui stoccare l'unico tgz da
installare, che poi potrebbe essere tranquillamente installato con
installpkg $tmptgzslacky/*
Quindi potrebbe essere spostato in una apposita dir contenente i tgz di
slacky.
mv $tmtgzslacky/* $cachetgzslacky
In fin dei conti, può darsi che abbia scordato qualcosa, ma non sembra 
un'impresa titanica...
inoltre si ha a disposizione anche il file PACKAGES.TXT da consultare
per risolvere eventuali dipendenze (chiaramente a mano...e possibilmente
dal repo ufficiale, mgari con slackpkg).
Il problema è che non so come estrapolare il link al tgz come ho detto
sopra. Bisogna usare sed? (non lo so usare e dovrei documentarmi...).
Se avete qualche idea fatevi avanti :-)

 Se avete qualche idea fatevi avanti :-)
appoggio la mozione;
r
-- 
Banana, nirvana, mañana (you know)
Banana, nirvana, mañana (I know)
Banana, nirvana, mañana (we know)
[Daevid Allen: Radio Gnome Invisible]


 
Più si è megli è  :-)

 gli array ma francamente mi pare un po' troppo a basso livello (no?).
Ok con sed è saltato fuori qualcosa, riepiloghiamo:
1- abbiamo il nostro file PACKAGES.TXT che contiene la riga in cui c'è
   l'indirizzo di mio interesse, che voglio isolare e attribuire ad una
   variabile.
2- se vi interessa la questione date un'occhiata al file in questione, è
   lampante capire cosa occorre fare. tali righe contengono il pattern
   LOCATION.
3- il comando da dare è
 
   grep LOCATION PACKAGES.TXT |grep -i rtorrent|sed 's/PACKAGE LOCATION:  .\///'
 
4- ci restituisce: "utilities/rtorrent/0.7.4" senza le virgolette che
   possiamo utilizzare per completare l'indirizzo del repository  di 
   nostro intresse che è 
 
   repo=
http://www.slacky.eu/repository/slackware-11.0/
   link=grep LOCATION PACKAGES.TXT |grep -i rtorrent|sed 's/PACKAGE LOCATION:  .\///'
   pkgurl=$repo$link
   "Mission complete! ;-)
5- quindi si può dare in pasto a wget il valore contenuto nella
   variabile link e scaricare il pacchetto nella directory desiderata
   $tmpkg per esempio:
   wget -P $tmpkg $pkgurl
 
   Quindi a questo punto dovremmo avere il pacchetto nella directory
   corrispondente alla variabile $tmpkg e da lì si può installare il
   tutto con i pkgtool (installpkg).
Insomma è solo un idea, ma dovrebbe essere semplice abbastanza per non
creare troppi problemi.
Alcuni possibili problemi:
la ricerca del link al pacchetto tgz si basa rigidamente su quella che
mi è sembrata l'impostazione del file PACKAGES.TXT, in particolare della
stringa "PACKAGE LOCATION:  ./indirizzo/pacchetto.tgz".
Ora, se questa forma non fosse rispettata altrettanto rigidamente da chi
mantiene il repository e venisse cambiata anche una virgola all'interno
della stringa in questione, allora andrebbe tutto a monte perchè sed
usato come ho fatto io, non fà altro che cancellare la prima parte della
stringa: "PACKAGE LOCATION:  ./" (ovviamente senza modificare il file
PACKAGES.TXT, è solo l'output che viene rielaborato).
Forse qualcuno che usa sed da più tempo di me sarà in grado di rendere
la rielaborazione più duttile ad eventuali anomalie all'interno del
file....
Detto ciò secondo me la forma di quel file non dovrebbe cambiare, ma
vado a naso...  ;-)
Bene, si accenttano commenti e correzioni, nonchè proposte migliorative.
Saluti  :-D

 stringa "PACKAGE LOCATION:  ./indirizzo/pacchetto.tgz".
c'è anche da vedere se anche gli altri repo seguono questa regola, 
altrimenti temo si dovrebbe fare un procedimento diverso per ognuno;
r
-- 
Hare hare supermarket !
Hare hare supermarket !
[Daevid Allen: Other Side of the Sky]
Ramapage: 
http://umpf.net/

 altrimenti temo si dovrebbe fare un procedimento diverso per ognuno;
 
Ah sì certo....questo procedimento funziona solo con 
slacky.eu
 e col suo
file PACKAGES.TXT.
Ho provatoa buttare giù un'abbozzo di script e ho provato ad installare
rtorrent: ha funzionato e rispetto a doversi cercare tutto a mano sul
sito è molto più elegante...nonchè meno faticoso per i miei gusti  ;-)
Una nota rispetto ai passaggi che vi avevo descritto nei post
precedenti. Per estrarre il link completo al file desiderato, non basta
estrapolare il percorso dalla stringa "PACKAGE LOCATION:" perchè
giustamente quello è solo il percorso. Allora bisogna accodarle anche il
nome esatto del pacchetto estrapolabile sempre con sed dalla stringa
"PACKAGE NAME:"  (si veda lo script di seguito...).
Va ancora completato, in particolare bisogna inserire la possibilità di
fare l'update del PACKAGES.TXT attraverso un parametro. E` che non mi
ricordavo come si gestiscono gli argomenti opzionali dopo il comando.
Poi bisognerebbe mettere mano alla gestione dei risultati multipli in
modo da consentire la scelta all'utente di ciò che vuole installare.
Infine per quanto riguarda altri repo, non avevo pensato a questa
possibilità...quindi non è contemplata dallo script.
Per il resto vi invito a provarlo e a modificarlo come più vi
aggrada...lo script dovrebbe essere abbastanza semplice ed accessibile
anche a chi, come me, è alle prime armi con lo scripting bash. ;-)
Ah..io l'ho chiamato pkg-get (con molta fantasia ;-) ).
Prima di provarlo date un'occhiata ai comandi che dà e alle directory
necessarie che vanno create prima di usarlo (una volta per tutte, ma
vanno create...). Và eseguito come root, perchè implica "installpkg" che
altrimenti non funzionerebbe (si potrebbe anche prevedere un'opzione che
richiede la password di root o qualcosa con sudo...).
ve lo posto scusandomi della lunghezza del post, ma era inevitabile...
-------------pkg-get--------------
#!/bin/bash
# set -x
clear # pulisce lo schermo
repo=
http://www.slacky.eu/repository/slackware-11.0/
pattern=$1 # pacchetto da installare
cache=/tmp/.cache-slacky-repo
# inserire aggiornamento PACKAGES.TXT in base ad 
# un parametro da aggiungere. quanto segue va 
# inserito in un blocco if...
# 
# if [ ls $cache/PACKAGES.TXT ]; then
#   rm $cache/PACKAGES.TXT
# fi
# wget -P $cache $repo"PACKAGES.TXT.gz"
# gunzip $cache"PACKAGES.TXT.gz"
# 
#
#
#
#
# ricerca link al pacchetto $pattern
link=$(grep LOCATION $cache/PACKAGES.TXT |grep -i $pattern |sed
's/PACKAGE LOCATION:  .\///')
name=$(grep "PACKAGE NAME" $cache/PACKAGES.TXT |grep -i $pattern |sed
's/PACKAGE NAME:  //')
urlpkg=$repo$link'/'$name
# mostra all'utente ciò che ha trovato
echo
echo "ho trovato" $urlpkg
echo
echo invio per proseguire Ctrl-c per interrompere e uscire
read
echo
echo
# download del pacchetto in una directory "ad hoc":
tmpdir=/tmp/.tmpdir.pkg
mkdir $tmpdir  # creo la directory che poi verrà eliminata
wget -c -P $tmpdir $urlpkg
# permette un controllo all'utente di ciò che ha scaricato
clear
echo
echo "ho scaricato il pacchetto" $(ls $tmpdir)
echo
echo "proseguo con l'aggiornamento/installazione?"
echo
echo invio per continuare Ctrl-c per interrompere.
read
clear
# installazione del pacchetto in questione
upgradepkg --install-new $tmpdir/*
# spostamento del tgz nella cache e rimozione della dir temporanea
mv $tmpdir/* $cache
rm -r $tmpdir
# controllo pacchetto installato
echo
echo CONTROLLO PRESENZA PACCHETTO....
echo 
echo $(ls /var/log/packages|grep -i $pattern)
echo
echo
echo invio per uscire
read
-------------------------------------------------------------
Come si può vedere è anche abbastanza interattivo. A questo proposito
penso che sarebbe possibile, provvisoriamente risolvere il problema dei
doppi pattern nel seguente modo.
lancio lo script con un pattern che sfortunatamente ricorre in più di un
pacchetto.
lo script mi dice quello che ha trovato e a quel punto invece di battere
invio e proseguire, mi annoto il pattern di ciò che mi interessa con più
precisione e dò ctrl-c.
Quindi rieseguo lo script dandogli in pasto il nuovo pattern univoco...
è un po' artificioso, ma se lo voleste provare con qualche paccetto che
ha un pattern non univoco...questa è un'idea. ;-)
Sono benvenute proposte e commenti.
A presto :-)

 A presto :-)
Saluti,
David
-- 
 . ''`.  Debian packager! | 
http://snipurl.com/gofoxygo/
 : :'  :   User #334216   |  
http://www.hanskalabs.net/
 `. `'`   GPG: 1392B174   | 
http://www.debianizzati.org/
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174

 PACKAGES.TXT, non ho un install-pkg... vabbè, hai capito :-P
Mi riservo domande e commenti riguardo le tue correzioni, molto gradite
e per le quali ti ringrazio. Come avrai potuto vedere sono alle prime
armi con lo scripting bash e tante ottimizzazioni mi sono oscure, ciò
nonostante, la semplicità e flessibilità di questo linguaggio mi ha
consentito di ottenere buono risultati dalla prima prova che ho fatto
ieri sera applicata ad rtorrent.
Per il momento rispondo solo a questa tua domanda:
per capire cosa intendo la cosa più semplice è scaricarti il file di
testo dall'indirizzo che vedi tra l'altro sotto la variabile repo, è
presente sia in forma estesa che in forma compressa in .gz.
Una volta che lo hai in locale prova ad usare come pattern "mplayer" e
ti accorgerai degli ovvi limiti di questo script, che tra l'altro và
proprio modificato, visto che il  percorso dove stà il pacchetto è una
cosa (riga PACKAGE LOCATION) e il suo nome è un'altra (riga PACKAGE NAME).
Provando il seguente comando sul file PACKAGE.TXT vedrai:
$ grep LOCATION PACKAGES.TXT |grep -i mplayer |sed 's/PACKAGE LOCATION:[ ]*\.\///'
multimedia/kmplayer/0.9.4a
multimedia/mplayer/1.0rc1try2
multimedia/mplayerplug-in/3.40
multimedia/mplayerthumbs/0.5b
multimedia/opera-mplayerplug-in/3.31
e anche questo:
$ grep NAME PACKAGES.TXT |grep -i mplayer |sed 's/PACKAGE NAME:[ ]*\.\///'
PACKAGE NAME:  kmplayer-0.9.4a-i486-1sl.tgz 
PACKAGE NAME:  mplayer-1.0rc1try2-i686-2sl.tgz 
PACKAGE NAME:  mplayerplug-in-3.40-i486-1gal.tgz 
PACKAGE NAME:  mplayerthumbs-0.5b-i486-2as.tgz 
PACKAGE NAME:  opera_mplayerplug-in-3.31-i686-2as.tgz 
Quindi in una situazione del genere l'utente dovrebbe avere la
possibilità di scegliere il pacchetto che vuole installare.
Noto e probabilmete è sempre così, che il primo risultato del primo
comando rappresenta il percorso del pacchetto il cui nome lo ritroviamo
nel primo risultato del secondo comando...cioè sono corrispondenti
percorso e nome. Si potrebbe sfruttare questa caratteristica per
facilitare un po' le cose...
Spero di averti risposto come ti aspettavi.
Grazie ancora.
A presto. :-)

 ve lo posto scusandomi della lunghezza del post, ma era inevitabile...
ok, più tardi lo provo;
r
-- 
- Berlusconi, lei è uno stronzo.
- Come si permette! La denuncio!
- L'ho detto con ironia.
- Ah. Allora niente, scusi.
Ramapage, Baudelaire, Pentangle: 
http://umpf.net/

 possibilità di scegliere il pacchetto che vuole installare.
be' gli fornisci la lista numerata e gli chiedi di inputtare il numero 
di quello che vuole installare -volendo più numeri o tutti o nessuno;
r
-- 
posted from a ridicoulus Country
Ramapage: 
http://umpf.net/

 A presto. :-)


 ok, più tardi lo provo;
Occhio ai pattern non univochi!  :-)
A presto.

 $ pkg-get remove <pacchetto>
Questo non serve:
se il pacchetto è installato si può disinstallare tranquillamente con
removepkg pacchetto.
Come al solito benvenute opinioni
Saluti

 Saluti
Saluti,


 Rilancio "pkget" senza trattino e con una "g" di meno, più corto... ;-P
surcontre: "ins" ;-P


 surcontre: "ins" ;-P
Mi piace più pkget, però ins è più corto...è un grosso problema...:-P

 L'ho detto: non conosco Slackware :-)
Cosa aspetti ad installarla!! ;-D))
Anche se non posso dirti gran chè: anch'io sono approdato da poco.
Bè comunque a quanto pare conosci Debian, che prima o poi proverò
anch'io....cambia il condimento ma è sempre pinguino no?.... ;-)

 (man read)
Mi documenterò meglio a riguardo...
Rinnovo il ringraziamento per la pazienza e la disponibilità dimostrata
:-)
A presto!  :-P

 A presto!  :-P
Saluti,
David
P.S.: sul wiki del mio blog trovi "Gestore", un package manager che
stavo scrivendo per la mia distribuzione ("Distro"... che fantasia,
eh?) in Bash. I pacchetti hanno estensione .pak, ma sono dei
comunissimi .tar.bz2. Ah, non è completo. 
http://wiki.hanskalabs.net/


 comunissimi .tar.bz2. Ah, non è completo. 
http://wiki.hanskalabs.net/
Cioè parti dai sorgenti??? mi piacerebbe l'idea...anzi non rispondere
vado a vedere subito..  :-D
Ciao, ci si sente!
grazie ancora!  :-)

 spero.
Ho messo mano allo script modificandolo nella direzione che vi avevo
anticipato. Dategli il nome che più vi aggrada. Se avete pazienza
leggete quanto segue.
Utilizzo:
pkget [-u] [pattern]
puo` essere lanciato anche solo con -u senza pattern, in tal caso
aggiornerà solo la lista dei pacchetti di 
slacky.eu
.
Funzionamento:
riceve un pattern e lo cerca nel file PACKAGES.TXT ritegliando le righe:
LOCATION e NAME.
Restituisce due elenchi numerati, uno contenente i nomi dei pacchetti
trovati e l'altro le rispettive locazioni, così si può verificare che
non vi siano errori di corrispondenza, cioè che il nome del pacchetto 2
corrisponda effettivamente alla locazione numero 2.
Chiede all'utente di scegliere il numero corrispondente al pacchetto
desiderato e quindi passa alla "costruzione" del link a tale pacchetto.
Chiede conferma per il download, lo scarica con wget, e chiede conferma
per l'installazione.
A questo punto lancia lo installa utilizzando upgradepkg
"--install-new", poichè sono richiesti i permessi di super utente tale
comando viene lanciato con sudo (bisogna far parte dei sudoers), se non
ne fate parte potete modificare lo script sostituendo "sudo upgrade..."
col semplice "upgradepkg..." utilizzandolo però come root.
Infine viene verificata la presenza del pacchetto in /var/log/packages.
Tra i limiti di questo script vi è quello di poter installare un
pacchetto alla volta...per ora lo lascio così, comunque dovrebbe essere
facilmente modificabile:
basta usare un ciclo in cui immettere le operazioni di ricerca e download,
dopodichè nella dir temporanea tmpdir.pkg ritroveremo non un solo
pacchetto, ma diversi e si ptranno installare con lo stesso comando che
ho inserito attualmente nello script: 
sudo upgradepkg --install-new $tmpdirpkg/*
così installa tutto in una botta sola...certo bisogna provare un po' e
vedere quali problemi saltano fuori.
Nel prossimo post vi invio lo script.
Sono graditi commenti e correzioni, nonchè idee per migliorarlo, magari
senza snaturarlo troppo.
A presto :-)

 A presto :-)
--------------------------------------------------------------------------
#!/bin/bash
# set -x
conferma ()
{
        pippo=0
        while [ $pippo == 0 ]; do
                echo "S per continuare n per uscire"
                read variabile
                case $variabile in
                        S|s|Y|y)
                                break ;;
                        N|n)
                                exit ;;
                        *)
                                continue
                esac
        done
}         
clear # pulisce lo schermo
repo=
http://www.slacky.eu/repository/slackware-11.0
cache=/tmp/.cache-slacky-repo
# Se non viene passato nessun argomento si restituisce un 
# messaggio di informazione sull'utilizzo dello script:
[ -z $1 ] && { echo "Utilizzo: `basename $0` [-u] <pacchetto>"
                exit 1
}
# se viene passato il flag "-u", allora si aggiorna la lista 
# dei pacchetti disponibili:
while getopts "u" OPT; do
        [ -f $cache/PACKAGES.TXT ] && rm $cache/PACKAGES.TXT
        cat << EOM
        aggiorno la lista dei pacchetti disponibili......
        dowload in corso.................................
EOM
        wget -P $cache $repo/PACKAGES.TXT.gz
        [ ! $? -eq 0 ] && { echo "problemi durante il download" 
                            read
                            exit 1
                          }
        gunzip $cache/PACKAGES.TXT.gz
        [ -f $cache/PACKAGES.TXT ] &&  echo "UPDATE COMPLETO... "
        conferma
done
shift $(( $OPTIND - 1 )) # serve per far puntare $1 all'argomento
                         # reale, nel notro caso il pattern di ricerca.
# Controllo che ci sia l'argomento, se non c'è allora significa che 
# l'utente voleva solo aggiornare la lista pacchetti...
[ -z $1 ] && exit 
pattern=$1 # pacchetto da installare
# ricerca dei pacchetti conteneti il pattern di ricerca
# la ricerca coinvolgerà il campo NAME e LOCATION in modo
# da poterle abbinare per la successiva costruzione del link
# da passare a wget.
# la lista dei nomi e delle ripettive locazioni vengono copiate
# in due file di testo temporanei.
tmpdirtxt=/tmp/.tmpdir.txt
tmpdirpkg=/tmp/.tmpdir.pkg
[ -e $tmpdirtxt ] && rm -r $tmpdirtxt # per sicurezza si eliminano
[ -e $tmpdirpkg ] && rm -r $tmpdirpkg # se esistono già...
mkdir $tmpdirtxt  # creo la directory che poi verrà eliminata: ospita i
file di testo
mkdir $tmpdirpkg  # creo la directory che poi verrà eliminata: ospita i
pacchetti
grep LOCATION $cache/PACKAGES.TXT |grep -i $pattern |sed 's/PACKAGE LOCATION:[ ]*\.\///' > $tmpdirtxt/link
grep "PACKAGE NAME" $cache/PACKAGES.TXT |grep -i $pattern |sed 's/PACKAGE NAME:[ ]*//' > $tmpdirtxt/name
# i risultati vengono numerati e mostrati all'utente, in modo che
# possano essere
# scelti agevolmente, premendo il numero corrispondente e battendo invio
cat <<EOM
Pacchetti trovati:
EOM
i=0
for riga in `cat $tmpdirtxt/name`; do
        echo $i $riga
        name[$i]=$riga
        i=$[$i+1]
done
cat <<EOM
Localizzati rispettivamente in:
EOM
i=0
for riga in `cat $tmpdirtxt/link`; do
        echo $i $riga
        locat[$i]=$riga
        i=$[$i+1]
done
cat <<EOM
scegli l'elemento
EOM
read scelta
cat <<EOM
Hai scelto:  ${name[$scelta]}
posizionato in ${locat[$scelta]}
il link completo è:
$repo/${locat[$scelta]}/${name[scelta]}"
EOM
urlpkg=$repo/${locat[$scelta]}/${name[scelta]}
cat <<EOM
Vuoi scaricare il pacchetto?
EOM
conferma
clear
# download del pacchetto in una directory "ad hoc":
wget -c -P $tmpdirpkg $urlpkg
# permette un controllo all'utente di ciò che ha scaricato
clear
cat<<EOM
ho scaricato il pacchetto $(ls $tmpdirpkg)
proseguo con l'aggiornamento/installazione?
EOM
conferma
clear
# installazione del pacchetto in questione
sudo upgradepkg --install-new $tmpdirpkg/*
# spostamento del tgz nella cache e rimozione delle dir temporanee
mv $tmpdirpkg/* $cache
rm -r $tmpdirpkg
rm -r $tmpdirtxt
# controllo pacchetto installato
cat <<EOM
CONTROLLO PRESENZA PACCHETTO......
CONFERMO LA PRESENZA IN /var/log/packages del seguente pacchetto:
$(ls /var/log/packages|grep -i $pattern)
EOM
-------------------------------------------------------------------------------------

 EOM
Che controllo è?
Qui confermi sempre, anche se l'ls non restituisce nulla.
Te lo immagini?
Confermo la presenza in /var/log/packages del pacchetto: .
Fai _realmente_ un controllo:
if ! [ -z "`ls /var/log/packages | grep -i $pattern`" ]
then
	echo "Confermo la presenza di $pattern in /var/log/packages."
	exit 0; #successo
else
	echo "$pattern non trovato!"
	exit 1; #errore
fi
Saluti,
David
-- 
 . ''`.  Debian maintainer | 
http://snipurl.com/gofoxygo/
 : :'  :  Linuxer #334216  |  
http://www.hanskalabs.net/


 Confermo la presenza in /var/log/packages del pacchetto: .
eh eh hai ragione è che questo serviva solo per confermare l'esito
positivo, in caso di esito negativo si sarebbe intervenuti a mano.
Comunque hai ragione...
Ti ringrazio della correzione e degli spunti.
Mi fa piacere che ti renda disponibile  :-)
Mi sono venute alcune idee che cambierebbero le carte in tavola
semplificando le cose e rendendo forse più stabile lo script.
Ma faccio un nuovo post...  ;-)

ho dato un'occhiata al repository di linuxpackages e con grande
sorpresa,
ma neanche troppa, ho visto che è presente anche lì un file casualmente
chiamato PACKAGES.TXT e organizzato come quello di 
slack.eu
.
Allora la curiosità mi ha portato su un repo ufficiale:
ftp://ftp.unina.it/pub/linux/distributions/slackware/slackware-11.0/
lì potete trovare il consueto PACKAGES.TXT che ha lo stesso formatodei
corrispondenti non ufficiali di cui sopra.
Il punto è che nello script ho scelto di individuare il nome del
pacchetto
sulla base di un patern di ricerca e di estrapolare dal FILE.TXT le
righe
"PACKAGE NAME" che lo contengono (il pattern). Questa direi che è una
scelta buona scelta, visto che in genere il pacchetto contiene nel suo
nome
il pattern immesso... cioè se voglio installare mplayer, allora userò
come
pattern mplayer e quasi sicuramente tra le righe "PACKAGE NAME" troverò
il
nome del pacchetto che voglio installare, perchè probabilmente si
chiamerà
"mplayer-.....".
Trovare però la locazione del pacchetto all'interno del repo, non è così
scontato...ommeglio dipende molto da come sono organizzate le directory
del
repo stesso.
Provate a scaricare il PACKAGES.TXT dal repo della slack 11.0 di
linuxpackages e usate il metodo di ricerca adottato dallo script per
cercare "mplayer":
vi ritornerà 5 nomi di pacchetto contenenti mplayer
e soltanto 3 percorsi !!!  :-\
Perchè???
perchè il percorso del pacchetto mplayer non contiene in tutti i casi il
pattern "mplayer". Nello specifico per esempio due pacchetti contenti
nel
loro nome il pattern mplayer, sono contenuti nel percorso "./ken/" e
così
non ne viene individuata la locazione...di conseguenza va a monte la
costruzione del link completo.
Morale: non si può fare affidamento sullo standard (se esiste) con cui
sono
organizzate le directory del repo.
La domanda allora diventa come trovare la locazione di un pacchetto e
come
abbinarla al nome corrispondente dello stesso pacchetto?
L'ideale sarebbe uno strumento in grado di accedere al repo e cercare
nelle
sue sottodirectory (anche se non so se possono essere chiamate così) il
nome e conseguentemente il percorso del pacchetto desiderato. Una
tecnica
del genere eviterebbe anche l'eventuale aggiornamento di file, perchè in
realtà non si baserebbe su alcun file del tipo PACKAGES.TXT, a tutto
vantaggio dell'elasticita di azione.
Insomma servirebbe una specie di find capace di operare usando come
"path"
l'indirizzo del repo e come "expression" il nostro pattern di ricerca.
Purtroppo io non conosco uno strumento del genere, che semplificherebbe
notevolmente le cose...
Se ne conoscete o avete idee in merito a quella tecnica,o volete
chiarimenti nel caso non mi fossi spiegato bene, non esitate a chiedere
o a
proporre.
Il problema potrebbe essere aggirato facendo affidamento
sull'impaginazione
del file PACKAGES.TXT, che, a quanto pare, ha un formato
standardizzato...almeno papparentemnte.
Basta darrgli un occhiata per accorgersi che per ogni pacchetto la riga
PACKAGE NAME: .....
è seguita dalla riga
PACKAGE LOCATION: .....
M'è venuto in mente un modo per associare nome a location dello stesso
pacchetto:
i=0
for riga in `cat PACKAGE.TXT`; do
        if [ riga contiene "NAME PACKAGE:" e contemporaneamente il
pattern]; then
           riga_nome=$i # memorizza il numero della riga
           estrapola il nome del paccheto da "riga"
        fi
        [ $i == $($riga_nome+1) ] "estrapola la locazione" # cioè se la
                                                           # riga è la
                                                           # successiva
                                                           # a
                                                           # riga_nome
                                                           # allora è
                                                           # quella
                                                           # contenente
                                                           # la
                                                           # locazione
                                                           # del
                                                           # pacchetto
        i=$[$i+1]
done
Non l'ho ancora provato, ma se funziona semnrerebbe più semplice...
Scusate la lunghezza, ma volevo chiarire la situazione, spero nella
vostra
pazienza...
Arrisentirci  :-)

 Ma faccio un nuovo post...  ;-)
Ora rispondo anche all'altro :-P


 Arrisentirci  :-)
Arrileggerci ;-)
Saluti,
David
-- 
 . ''`.  Debian maintainer | 
http://snipurl.com/gofoxygo/
 : :'  :  Linuxer #334216  |  
http://www.hanskalabs.net/


 mai :-P)
Eh eh, io sarei per l'open source...anche se mi sfugge come facciano
acampare i programmatori che sposano questa filosofia...
Saluti

 Saluti
Altrettanto,


 il tutto in php ;-)
Ehm, devo essere sincero non conosco nulla di php.
Non so cosa siano le regex.
In soldoni non ho capito una mazza di quello che stai dicendo  ;-)
Chiedendoti di fare un po' di luce sulla questione, chiedo scusa per
l'ignoranza.
Però l'impressione è quella che il messaggio non sia arrivato,
correggimi se sbaglio...
Dunque io intendevo usare uno strumento, un comando che lavorasse
direttamente in remoto e scandagliasse le directory del repo remoto
in cerca del pattern inserito.
Se ponessimo di avere il repo in locale, come fosse una directory
qualsiasi, useremmo find (ad esempio)
$ find $repodir -name $pattern
Mi capisci? cioè immagina di avere in locale questa directory $repo
che contiene varie sotto directory che a loro volta ne contengono altre
e alla fine contengono anche i pacchetti ".tgz".
Col comando sopra saremmo slegati da eventuali formati non standard dei
file di testo ecc.
Inoltre anche il programma diventerebbe pi semplice, mi pare.
Ora, purtroppo non abbiamo in locale tale dir e non ho intenzione di
mettere su un mirror al repo...
Ma da qualche parte ci sarà in rete quella directory tantèvvero che
riusciamo a navigarla.
Mi chiedevo  quel punto se esistesse qualcosa di semplice come find in
grado di scandagliare le directory remote...
Mi rendo conto che potrebbe essere una richiesta stupida, ma dal momento
che ignoro i protocolli e le problematiche della rete, chiedo....

 fai un software più articolato e complesso... sì :-)
Ah ecco...
Mi risulta un po' annebbiata la faccenda...sarà perchè sono fuori
dall'ambiente in questione.
Però io faccio un software e lo rilascio in gpl.
metti che un'altro programmatore si offra ad un cliente per adattarlo e
dargli supporto e si acchiappi la pagnotta...
Tutto lecito? Tutto deontologicamente accettabile?
La butto lì senza esprimere opinioni...solo da ignorante in materia.
Anzi non vorrei sporcare troppo questo treath che riguarda altro.
A presto!

 chiedo....
Figurati, non è un problema.
Questo package manager mi sta "intrippando" :-P
Saluti,
David
[1] 
http://it.wikipedia.org/wiki/Espressione_regolare


 A presto!
Ciao,


 neppure un eventuale impiegato. :-)
Ok grazie della spiegazione.

 
lo andro a vedere senz'altro...m'era sfuggita l'abbrviazione.

 PACKAGES.TXT.
Allora, ho provato ad usare questa idea che mi è venuta, ma ho
riscontrato un grosso problemadi lentezza.
Vi posto subito lo script invitandovi a provarlo.
--------------------------------------------------------------------
#!/bin/bash
pattern=$1
repo=
http://repo
cachefile=/tmp/.cache-slacky-repo/PACKAGE.TXT
i=0
v=0
ii=-111
while read riga; do
        echo "$riga" |grep "PACKAGE NAME" |grep -i $pattern > /dev/null
        if [ $? -eq 0 ]; then
             name[$v]=$(echo $riga |sed 's/PACKAGE NAME:[ ]*//')
             ii=$[$i]
        fi
        if [ $i -eq  $[$ii+1] ]; then
             location[$v]=$(echo $riga |sed 's/PACKAGE LOCATION:[ ]*//')
             echo "$v   ${name[$v]}  ${location[$v]}"
             link[$v]=$repo/${location[$v]}/${name[$v]}
             v=$[$v+1]
        fi
        i=$[$i+1]
done < $cachefile
--------------------------------------------------------------------
Legge direttamente dal file di testo trattendolo come un elenco.
Per ogni riga che viene letta.....vedi script
Mi interesserebbe capire per quale motivo impiega così tanto a
restituire i risultati...se penso che grep ha una velocità
impercettibile, mi viene da pensare che grep lavori diversamente dalla
lettura riga per riga.
Se volete fare una prova più rapida provate ad assegnare alla variabile
cachefile il seguente file che ho chiamato elenco
---------------------------------------------------------------------
PACKAGE NAME:  pane
PACKAGE LOCATION: bottega
bla
blmsalkn
sdasassd
PACKAGE NAME:  pane_e_salame
PACKAGE LOCATION:  salumeria
asdadczxcx
xxzczxc
czxczx
czz
PACKAGE NAME:  pane_e_vino
PACKAGE LOCATION:  enoteca
rtbrb
rbb
rb
PACKAGE NAME:  acqua_gassata
PACKAGE LOCATION:  frigo
PACKAGE NAME:  cipolle
PACKAGE LOCATION:  orto
PACKAGE NAME:  pomodori
PACKAGE LOCATION: orto
PACKAGE NAME:  pane_latte
PACKAGE LOCATION: latteria
----------------------------------------------------------------------
Chiedo scusa per la fantasia! ;-)
provate a far girare lo script con pane come argomento (pattern)
@David
Sto lavorando anche alla tua idea, non l'ho accantonata....
Anzi, mi sa che sarà indispensabile.
PS: come faccio con grep a cercare le righe contenenti
contemporaneamente due pattern?
chiaramente senza usare la pipe.
PS1. come faccio a ricercare una parola in una stringa (non in un file,
proprio in una stringa...). Non sono riuscito a trovare nulla...

 file, proprio in una stringa...). Non sono riuscito a trovare nulla...
Sempre con grep? Però grep ti restituisce tutta la stringa... uhm, ci
penserò. (Comunque, che devi farci?)


 penserò. (Comunque, che devi farci?)
guarda il test per vedere se la riga contiene pattern e "PACKAGE NAME",
quello che mi hi corretto con la regex:
ho dovuto tirare in ballo echo e minimo una pipe a grep, ci sarà pure
qualcosa di più semplice no?
Volevo risponderti prima, ma non riuscivo a visualizzare il tuo
messaggio sul newsreader (probabilmente problemi di cacheing dei
messaggi ...). Fortuna che l'ho letto per sbaglio da google... :-)
Saluti

 
Se vuoi continuiamo in privato, che mi pare che stiamo intasando il
NG :-)


 David
Per me va bene, visto che ormai siamo gli unici due interlocutori della
discussione... :-(
Peccato però che in questo modo chi sta seguendo la discussione, anche
senza intervenire, non potrà più leggere gli sviluppi della faccenda.
Magari il risultato (o i risultati alternativi) che slterà fuori lo
posteremo anche nel ng così da dare una completezza alla discussione e
rendere disponibile agli amici slackysti una alternativa un po' più
comoda per la ricerca, download e installazione dei pacchetti dai repo
principali.  :-P
Inoltre chissa che qualcuno non possa fare sua l'idea di base e creare
qualcosa di migliore....(tanto per restare in ambito open).  ;-)
Ad ogni modo, se vuoi fare via mail, ecco il mio indirizzo valido:
l'indirizzo è "scripting" (senza le virgolette ovviamente)
il dominio è lavabit punto com.
Penso che non avrai difficoltà a ricavare l'indirizzo corretto. ;-)
Ancora una volta ringrazio la tua disponibilità.
A presto! :-)

 discussione... :-(
Ma mica siete gli unici due che leggono.
Una volta tanto che c'e' un thread bello corposo con informazioni utili
che saranno una manna per i futuri utenti di google, vuoi togliere loro
la possibilita' di sviscerare gli stessi passi?
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 togliere loro la possibilita' di sviscerare gli stessi passi?
Hai ragione. :-)
Più che altro mi veniva difficile trovare il thread, visto che
Claws-Mail li ordina secondo la data del primo post (che "risale" al 2
giugno)... ma risolverò il problema allora :-)
Intanto porto una novità: Johnny Newbie ha fatto un test
sull'efficienza di `cat file` contro un ciclo while con read. L'ho
appena rifatto, e i risultati sono:
$ time cat PACKAGES.TXT
...
real    0m3.404s
user    0m0.000s
sys     0m0.088s
$ time ./script
...
real    0m7.265s
user    0m3.232s
sys     0m0.292s
$
(dove script è:
#!/bin/bash
while read riga; do
echo $riga
done < PACKAGES.TXT
)
Quindi, _ovviamente_, il problema è quel read con il while. Il prossimo
passo è, quindi: usare cat con l'utilizzo di file intermedi. Aspettiamo
notizie da JohnnyNewbie ora ;-)
Saluti,


 la possibilita' di sviscerare gli stessi passi?
mi associo, anche se ci capisco ben poco, ci ho messo un'oretta e passa 
per fare uno script elementare come questo:
#!/bin/bash
echo
ora=$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq);
if [ $ora -eq 1000000 ]; then
    echo
    echo "2200000" >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
    echo avviato ondemand 1-2,2 GHz
else
   echo
   echo "1000000" >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
   echo frequenza fissata a 1 GHz
fi
  echo
  echo
cpufreq-info
però ho capito subito perché al riavvio non funzionava ;-P
r
-- 
FELICE BLOOMSDAY 2007!
Home Page, The Pentangle, I Salon di Baudelaire: 
http://www.umpf.net

 r
Saluti,


 paio, tra cui mysql e mplayer).
Sapevo che l'idea di parlare in privato non era il massimo e che avrei
dovuto ripetere (reptita juvant...diacevano... :-/ sed etiam magna 
rotturam est...aggiungerei ;-p ).
Allora ricapitolando diciamo che sono state mescolate le carte ed è
venuta fuori una soluzione ibrida, come già anticipato David:
ve la accenno soltanto riportandovi uno scriptino di prova che partendo
dal file PACKAGES.TXT crea il solito elenco numerato:
numero - pacchetto - posizione.
--------------------------------
#!/bin/bash
# set -x
pattern=$1
repo=
http://repo
cachefile=/tmp/.cache-slacky-repo/PACKAGES.TXT
#cachefile=~/tmp/script/pkgmanager/elenco
accessorio=~/tmp/script/pkgmanager/accessorio
# grep preventivo del cachefile:
# serve per ridurne le dimensioni in modo da rendere
# più rapido il successivo scandagliamento col read:
grep -A1 -i "^PACKAGE NAME:.*$pattern" $cachefile > $accessorio
#grep -A1 "PACKAGE NAME" | grep -A1 -i $pattern > $accessorio
i=0
v=0
ii=-111
while read riga; do
        echo "$riga" |grep "PACKAGE NAME" |grep -i $pattern > /dev/null
        if [ $? -eq 0 ]; then
             name[$v]=$(echo $riga |sed 's/PACKAGE NAME:[ ]*//')
            ii=$[$i]
        fi
        if [ $i -eq  $[$ii+1] ]; then
             location[$v]=$(echo $riga |sed 's/PACKAGE LOCATION:[ ]*//')
             echo "$v   ${name[$v]}  ${location[$v]}"
             v=$[$v+1]
        fi
      i=$[$i+1]
done < $accessorio
echo "scegline uno"
read n
link[$n]=$repo/${location[$n]}/${name[$n]}
------------------------------------------------
oltre a scrivere l'elenco numerato, consente la scelta e crea
l'indirizzo da dare in pasto a wget.
L'idea, come, anticipava David è questa:
read legge riga per riga e mi è semplice controllare le operazioni che
compie, dando razionalità al tutto. Però è drammaticamente lento.
grep e sed senza il read devono appoggiarsi su file acessori da
rielaborare, e laprogrammazione, a mio modo di vedere risulta meno
chiara e più complicata. Però sono rapidissimi nello scandagliamento dei
file di testo.
Morale mi appoggio su un file accessorio che riporta le righe che mi
interessano del grosso PACKAGE.TXT. il file acessorio conterrà solo
poche righe a seconda del pattern (che deve essere inserito con un certo
criterio...insomma si presume che l'utente sia mediamente
cerebrodotato ;-) ).
Quindi si rielabora il file così creato con il ciclo "while read" che a
quel punto anche se lento non importa più, visto che abbiamo a che fare
con un file di una decina di righe...
Provate pure... se volete: ovvio che dovete modificare qualche
variabile.
A breve (oggi o domani) posterò una versione completa da sottoporre a
critiche e suggerimenti.
Vi anticipo che, visto che i file PACKAGES.TXT sono standard nella forma
per diversi repo, non c'è motivo di ridurci al solo 
slacky.it
.
si potrebbe inserire una scelta iniziale che consenta all'utente di
scegliere dove cerare il pacchetto oppure cercare dappertutto e inserire
nell'elenco anche il repo in cui si trova il pacchetto...vedremo un
po'...  :-)
In ogni caso restano in piedi le domande precedenti:
1- perche read è così lento rispetto a grep o a cat?

 Se ti interessa.. ho appena scaricato i sorgenti di grep  :-)
Sono andato sul sito (interfaccia web del CVS...non che sappia cosa
significhi...). Ho trovato i sorgenti che come immagginavo sono scritti
in c.
Se riesci a capirci qualcosa fai pure sapere...io non mi avvanturo
neanche nell'impresa di capire, la lettura dei sorgenti, mi ha già
confermato che non ci capirei una mazza.  :-(
Speravo in un di quei bei documenti in italiano stile ildp del sito del
pluto che ti spiegano in modo semplice come funzionano le cose...
Ma per sapere come lavora grep, non so se ne esistono, io non ne ho
trovati...
Comunque, a quanto pare la soluzione ibrida accorcia i tempi e funziona
anche, sto sistemando lo script nella sua ultima versione così appena lo
posto potrete già fare una prova.

 po'...  :-)
direi che la cosa migliore sarebbe poter impostare l'affidabilità dei 
repo, specie per chi non ha una banda larga, così se lo trova nel primo, 
di affidabilità più alta, il programma si ferma, altrimenti cerca nel o 
nei successivi;


 nei successivi;
Razionalemnte non ti dò torto però:
1- qual'è il più affidabile?
   già che ci siamo fai il nome di qualche repo oltre slacky e
   linuxpackages .
2- come avrai capito la questione si porrebbe solo se fosse la prima
   volta che si usa lo script o se si vuole fare l'update del contenuto
   del repo. In queste occasioni (e la seconda è quasi sempre
   ricorrente...), infatti, verrebbero scaricati i file PACKAGES.TXT
   dei vari repo.
   Nella pratica anche non avendo banda larga...non camibia molto, visto
   che le versioni compresse di questi file sono di circa 200 - 300 KB.
   Perciò cambia poco scaricarene uno o tutti...anche perchè, che io
   conosco solo due repo non ufficiali...
3- mi dirai che operando su tutti i file in ogni caso, anche
   l'efficienza dello script si riduce...vero. Ma in termini di tempo
   questo è ancor meno rilevante del punto 2.
Tuttavia, la proposta è saggia e sarà èresa in considerazione.
Dal lato utente direi allora che ci si vorrebbe aspettare un bell'elenco
con una voce in più rispetto a prima, del tipo:
n)  PACCHETTO   LOCATION   REPO
Però a ben pensare... e mi viene in mente ora...
lo script è efficace anche qualora l'utente non conosca di preciso il
nome del pacchetto.
Mettiamo che io voglia cercare un client p2p per rete bit-torrent e che
non sappia di preciso come si chiama...bene proverò a cercare il pattern
"torrent".
Se interrompessi la ricerca al primo repo, potrebbe verificarsi il
fatto che magari sul repo1 avrei bittorren e libtorrent (è solo un esempio)
e potrebbe darsi che sul repo2 ci sia anche rtorrent e ktorrent...
Quindi di fatto la mia ricerca sarebbe limitata!
Le opzioni su come organizzare lo script sono molte, però bisogna stare
attenti perchè è facile ottenere uno strumento più ottimizzato e rapido,
ma che rischia di essere limitato!  ;-)
Si potrebbe aggiungere anche un opzione -s che potrebbe significare
"cerca" e solo in quel caso si cercherebbe d'appertutto, altrimenti si
cerca in base a priorità, come si vede la cosa si complica.
Resto dell'idea che visto che i repo sono pochi ed in caso di update
vengono scaricati 500 k circa, tanto vale scaricarli tutti e restituire
tutti i pacchetti disponibili...logicamente accompagati dal proprio
repo.
A quel punto l'utente sceglirà il pacchetto premendo il numerino
corrispondente.
Altre idee sono bene accette...anche perchè se i repo fossero molti di
più allora le cose cambierebbero.
Ho provato il pkget con la "nuova" tecnica ibrida di cui parlavamo nei
post precedenti:
funziona ed è anche sufficientemente rapida, comunque si ha a occhio
l'impressione che le righe vengano scritte una per una e non stampate
tutte insieme....poco male, in fin dei conti per questo scopo si tratta
di decisecondi! ;-)
Arileggerci allora   :-D

 di decisecondi! ;-)
be', non è che i vari yum-yast-quack siano dei fulmini, di sicuro il tuo 
script li surclassa in fase d'installazione;


 script li surclassa in fase d'installazione;
Confermo che yum, almeno nella versione che ho io non è un fulmine, ma
a me dà noia l'interrogazione di tutti i repo (non sonosolo tre come qua)
Inoltre sono tutti abbastanza intasati, quindi con la mia connessione la
lentezza è padrona.
Poi trova molti pacchetti e che ci metta il suo tempo a scrivere mi pare
anche giusto. In fase d'installazione penso s'appoggi su rpm, non
saprei, io non ho mai avuto grossi problemi.
Più che altro li surclasserà in digitazione.... eh eh :-D
Dell'installazione non ho inventato nulla installpkg fà tutto lui ;-)
Saluti :-)

 saprei, io non ho mai avuto grossi problemi.
era una quasi battuta, ovvio che installpkg o upgradepkg sono i più 
veloci in assoluto: se ne impipano delle dipendenze e girano sulla Slack;
ok, quando dici che è pronto passo alla Slack e provo lo script;
avete qlc pacchetto interessante da suggerire?


 Saluti :-)
Spero di esserti stato d'aiuto (anche) stasera ;-)


 David
A presto e se trovi risposte dai sorgeti del grep fammi sapere! :-p

 A presto e se trovi risposte dai sorgeti del grep fammi sapere! :-p
Per quelle ci vorrà un oracolo, mi sa.
Torno al mio pkget con dialog ;-)


 avete qlc pacchetto interessante da suggerire?
mmmm, in effetti non sono un grande installatore, non saprei cosa
consigliarti, comunque potrai apprezzarne l'efficacia con un pattern
piuttosto generico così ti salta fuori l'elenco e scegli il numerino....
A dirla tutta sono rimasto veramente soddisfatto del risultato...
Che so prova ad installare un client bit-torrent...
Comunque per ora devo ancora completarlo, potrei già postare qualcosa,
ma poi David mi bacchetta con la sintassi :-D ;-) :-p
Meglio ritoccarlo un po'.
Saluti

 Slack? O non aggiornate mai? ;-)
distro che vince non si cambia;
personalmente aggiorno solo se ci sono pacchetti di sicurezza, ecco gli 
ultimi:
2007-06-01 - [slackware-security] firefox-seamonkey-thunderbird 
(SSA:2007-152-02)
2007-06-01 - [slackware-security] php5 (SSA:2007-152-01)
2007-05-16 - [slackware-security] libpng (SSA:2007-136-01)
2007-05-14 - [slackware-security] samba (SSA:2007-134-01)
2007-05-07 - [slackware-security] php (SSA:2007-127-01)
2007-04-20 - [slackware-security] Slackware 11.0 x11-6.9.0 patch fix 
(SSA:2007-110-01)
2007-04-19 - [slackware-security] freetype (SSA:2007-109-01)
2007-04-19 - [slackware-security] xine-lib (SSA:2007-109-02)
e nat. solo per quello che ho installato, quindi niente samba ad es;
stavo ammattendo con Fedora che ad ogni avvio vuole aggiornare dei 
pacchetti, tanto che ho disabilitato l'aggeggio automatico;
però in molti usano swaret o roba simile che hanno qlc di simile ad 
apt-get update, specie quelli che hanno una current, dove gli 
aggiornamenti sono frequenti (e quando si diradano subito ci si mette a 
strillare che è imminente l'uscita della nuova versione);


 Torno al mio pkget con dialog ;-)
Va bè io andrò in branda.
Ci si risente!
:-)

 e nat. solo per quello che ho installato, quindi niente samba ad es;
Come procedi con all'aggiornamento upgradepkg pacchetto per pacchetto?
E quegli aggiornamenti sulla sicurezza sono sul sito ufficiale?
La mia ignoranza a volte mi spiazza .-(

 Meglio ritoccarlo un po'.
non c'è fretta, c'è tempo per includerlo nella 11.1 ;-P
r
-- 
FELICE BLOOMSDAY 2007!
Home Page, The Pentangle, I Salon di Baudelaire: 
http://www.umpf.net

 non c'è fretta, c'è tempo per includerlo nella 11.1 ;-P
Lì mi sa che mi bacchetterebbe Pat...altro che 11.1!! :-P

 Come procedi con all'aggiornamento upgradepkg pacchetto per pacchetto?
sì, più in particolare:
vedo gli aggiornamenti in 
http://www.slackware.com/security/list.php?l=slackware-security&y=2007
,
controllo se è roba che mi serve in file:///var/log/packages, se sì lo 
scarico e da shell faccio
# up
che è uno script (per modo di dire, in pratica un alias) per upgradepkg 
*.tgz;
uhm, mi sa che ti toccherà fare un altro script per fare tutto questo in 
automatico ;-P


 automatico ;-P
Ci stavo giusto pensando, anche se ripeto, secondo me sta volta c'è gia
slackpkg che accede direttamente al repo uficiale...boo
vedremo... se già fa tutto lui bene, altrimenti chissà.... :-)

 vedremo... se già fa tutto lui bene, altrimenti chissà.... :-)
indagherò anch'io su slackpkg, è forse ora che mi automatizzi un po';


 Torno al mio pkget con dialog ;-)
Ho partorito una versione "minima": la grafica e il file di
configurazione :-)
"Ovviamente" manca tutta la parte cui sta lavorando JohnnyNewbie, ossia
l'installazione, la rimozione e l'aggiornamento dei pacchetti.
Ovviamente, non conoscendo i repository, ho messo uno "Slackware
Official Repository", uno "Slacky Repository" e uno "Altro Repository".
Inoltre, invece degli indirizzi http://.* ho usato i nomi "slackware",
"slacky", "altro". Giusto per vedere se andava il tutto ;-)
Ho già inviato un .tar.bz2 a JohnnyNewbie, Rama, se vuoi anche tu,
mandami la tua mail.
= INSTALL =
tar jxvf pkget.tar.bz2
cd pkget
./pkget.sh
Dipendenze: dialog :-)
OVVIAMENTE lo script attualmente ha tutti i file di configurazione in
`pwd`. Come potrete vedere nello script, infatti, le righe "ufficiali"
sono commentate (della serie che ci vorrebbe una dir
in /usr/share/pkget/, mentre io ho creato `pwd`/share/pkget/...
naturalmente è tutto configurabile ;-) )
Enjoy!
Saluti,
David
-- 
 . ''`.  Debian maintainer | 
http://snipurl.com/gofoxygo/
 : :'  :  Linuxer #334216  |  
http://www.hanskalabs.net/
 `. `'`    GPG: 1392B174   | 
http://www.debianizzati.org/
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174

>> Meglio ritoccarlo un po'.
Nuove notizie:
1- ho adeguato lo script in modo che reperisca i pacchetti da tutti e
   tre i repo che fino ad ora conosco: ufficiali, slacy, linuxpackages.
   Riepilogo:
   - come anticipato ieri l'utente che è intenzionato ad aggiornare
     la lista dei pacchetti e a cercare ed installare un pacchetto:
     dpkg -u pattern
 
     Questo è l'utilizzo completo, poi se si ommette l'argomento non
     viene eseguita la ricerca, oppure se viene ommesso il flag -u non
     viene eseguito l'update. Inoltre ogni passaggio è ben distinto
     da una richiesta di conferma, che permette tra l'altro di uscire.
     Insomma o cercato di rendere tutto un po' versatile e adattabile
     all'esigenza.
     Ponendo di eseguire tutti i passaggi fino all'installazione si dà
     il comando sopra.
     l'utente vedrà aggiornarsi tutti e tre i repo:
     sfortuna ha voluto che sul repo ufficiale non ci sia laversione
     compressa del PACKAGES.TXT, questo ha complicato un attimo anche la
     fase di programmazione dell'update.
     A questo punto confermando positivamente di continuare, viene
     stampato l'elenco numerato con:
     NUMERO REPO  NOME-PACCHETTO  PERCORSO-INDIRIZZO
     Si sceglie il numero che si vuole e si prosegue confermando.
     Volendo si può anche uscire, così lo script ha assolto la funzione
     di ricercatore di paccchetti (ommeglio di pattern).
     Confermando invece viene scaricato il pacchetto con wget.
     A questo punto si può decidere di uscire oppure proseguire con
     l'installazione. Nel primo caso avremo solo scaricato il tgz e
     stoccato in una cache...ahh.. ora ci sono tre sotto-cache una per
     ogli repo: io ho usato qualcosa di simile a:
     /tmp/.cache-pkget/nome-repo/
     così resta tutto separato.
     Infine se si prosegue con l'installazione viene richiesta la
     password di root o in alternativa, se facciamo parte dei sudoers, la
     propria password (ancora da fare, non completato).
     Dopodichè si verifica il tutto e si ottiene un messaggio di
     avvertimento se l'installazione non è andata a buon fine (ancora da
     fare).
2- Da fare:
 
   2.1- Verifica installazione: come consigliato da David
 
   2.2- mettere apposto la questione della richiesta della password
 
   2.3- Ottimizzare lo scaricamento con wget in modo che se si ha a che
        fare con pacchetti voluminosi, si possa eventualmente riprendere
	il download in un secondo momento. Non sono rare le cadute di
	linea per chi ha connessioni come la mia o analogica
	tradizionale...insomma il resume è d'obbligo. Non sò ancora come
	sviluppare questa parte..quindi se avete proposte...
	Si potrebbe mettere una seconda opzione che nel caso si voglia
	riprendere un download acceda solamente ad un file in cui vi è
	l'indirizzo del pacchetto non completato, e poi dare 
	wget -c -O stessonomediprima -P stessadir url
	Qualcosa così insomma, ma se avete idee migliori dite pure.
 
   2.4- Si potrebbe rendere l'elenco dei pacchetti meglio consultabile,
        qualora si voglia cercare un pattern molto molto generico; mi
	spiego:
	volevo fare una prova in modo che il pattern coinvolgesse tutti
	e tre i repo per vedre come veniva e ho immesso il pattern "lib".
	L'elenco non finiva più!!  ;-)
	E era difficile trovare qualcosa con così tante righe.
	chiaramente è un caso di ricerca fuori dal comune...lo script
	non è pensato per questo scopo. Però avrei pensato che si
	potrebbe spedire l'elenco in output ad un file temporaneo e
	visualizzarlo con una pipe a less, che tra l'aòtro permetterebbe
	eventuali ricerche manuali.
	chissà se funziona la seguente tecnica:
 
	echo "premi q per uscire dalla visualizzazione dell'elenco"
	conferma
	while read $riga; do
	  bla
	  bla
	done < $tmp |less
 
	boo, l'unica è provare, l'importante è che quando esco da less
	prosegua lo script....
	Questa è solo un idea che darebbe qualche fronzolo in più....ma
	nulla di prioritario per carità, non fissiamoci troppo su queste
	cose, se avete idee comunque dite pure eh... :-)
   2.5- Valutare la possibilità di una semplice interfaccia in ncurses
        grazie all'impegno di David (a causa della mia imbranataggine
	con seamonkeymail, mi è sparito l'allegato che conteneva il
	tar.bz2...non posso ancora valutarla..).
	Anche questo punto non è comunque prioritario....comumque se non
	altro potrebbe servire per prendere confidenza con dialog
Mi pare che non c'è altro da aggiunngere.
Solo una cosa, ho provato un po' lo script, che per quantosopra, non è
completo.
Tuttavia il grosso del lavoro lo fà ed è già sufficiente per cercare
scaricare ed installare i pacchetti dei repo.
Visto, inoltre che più si è a testare e  meglio è, potrei postarlo
ugualmente così che possiate provarlo un po'.
L'avrei già fatto, ma visto che è un po' lungo (non che questo post sia
corto...) ho preferito chiedere prima.
Che ne dite?
Fatemi sapere, così o sta sera o domattina se mai lo posto. ;-)
Bye! :-D

 Che ne dite? 
non hai un sito? lo metti lì e posti il link;


 non hai un sito? lo metti lì e posti il link;
Non ho siti.... :-(
magari domani lo posto qui....vedo un po'...
A dire il vero avevo sottoscritto un account su altervista, ma ho usato
il servizio solo come ftp per passarmi della roba in remoto e poterla
scaricare poi da casa...(mi sa che ora sarà anche scaduto).
Non ho idea di come si faccia un sito, perchè non ne ho mai fatto. :-(
l'ignoranza regna sovrana...
Ci vuole molto ad imparare? o bastano pochi passaggi?
chissà potrebbe essere l'occasione per imparare.... ;-)

 chissà potrebbe essere l'occasione per imparare.... ;-)
non ci vuol molto, visto che il web ne è infestato;
eppoi non è neanche necessario, ti basta avere l'indirizzo e schiaffare 
lì il file -a questo proposito, quei mentecatti di Alice ti danno già 
bell'e pronto qlc tipo 
tuoindir...@alice.it
, per poi venderti 
l'antispam, immagino;
ora va di moda myspace che presumo ti dia un sito già impostato;
un'altra alternativa è passare il file a me o a Davide per metterlo nei 
nostri siti;
ma se si tratta di pochi kb non vedo perché non postarlo qui, se non ci 
sono voci contrarie: non credo sia più pesante dei vari log che spesso 
si postano;


 si postano;
Si, lo posterò qui....
Comunque su altervista potevi mettere lì roba via ftp, ma la pagina
risultava sempre in fase di costruzione. Mi documenterò un attimo, può
sempre servire avere o saper mettere su un sito web rapidamente.
Va bè... tra un po' lo posto.

 ugualmente così che possiate provarlo un po'.
-----------------------------------------------------------------------------
#!/bin/bash
# set -x
################### FUNZIONE DI CONFERMA ***************
conferma ()
{
        pippo=0
        while [ $pippo == 0 ]; do
                echo "S per continuare n per uscire"
                read variabile
                case $variabile in
                        S|s|Y|y)
                                break ;;
                        N|n)
                                exit ;;
                        *)
                                continue
                esac
        done
}         
################## DICHIARAZIONE VETTORI ##################
clear # pulisce lo schermo
# Definizione dei repo e rispettiva cache
repo[1]=
ftp://ftp.eutelia.it/pub/Slackware_Mirror/slackware-11.0
cache[1]=/tmp/.cache-slacky-repo/ufficiale
reponame[1]="OFFICIAL"
repo[2]=
http://www.slacky.eu/repository/slackware-11.0
cache[2]=/tmp/.cache-slacky-repo/slacky
reponame[2]="SLACKY"
repo[3]=
http://linuxpackages.inode.at/Slackware-11.0
cache[3]=/tmp/.cache-slacky-repo/linuxpackages
reponame[3]="LINUXPACKAGES"
################# CONTROLLO ARGOMENTI ######################
# Se non viene passato nessun argomento si restituisce un 
# messaggio di informazione sull'utilizzo dello script:
[ -z $1 ] && { echo "Utilizzo: `basename $0` [-u] <pacchetto>"
                exit 1
}
####################### UPDATE REPOSITORIES ###############################
# se viene passato il flag "-u", allora si aggiorna la lista 
# dei pacchetti disponibili:
while getopts "u" OPT; do
   for i in 1 2 3; do
        [ -f ${cache[$i]}/PACKAGES.TXT ] && rm ${cache[$i]}/PACKAGES.TXT
        cat << EOM
        REPO ${reponame[$i]}: AGGIORNAMENTO LISTA PACCHETTI DISPONIBILI
EOM
        ! [ -e ${cache[$i]} ] && mkdir ${cache[$i]} # crea la cachedir se non esiste
        if [ $i -eq 1 ]; then
            wget -P ${cache[$i]} ${repo[$i]}/PACKAGES.TXT
         else
            wget -P ${cache[$i]} ${repo[$i]}/PACKAGES.TXT.gz
        fi 
        [ ! $? -eq 0 ] && { echo "problemi durante il download" 
                            read
                            exit 1
                          }
        [ -f ${cache[$i]}/PACKAGES.TXT.gz ] && gunzip ${cache[$i]}/PACKAGES.TXT.gz
        [ -f ${cache[$i]}/PACKAGES.TXT ] &&  echo repo $i "UPDATE COMPLETO... "
   done
        conferma
done
shift $(( $OPTIND - 1 )) # serve per far puntare $1 all'argomento
                         # reale, nel notro caso il pattern di ricerca.
################### CONTROLLO ALTRI ARGOMENTI ######################
# Controllo che ci sia l'argomento, se non c'è allora significa che 
# l'utente voleva solo aggiornare la lista pacchetti...
[ -z $1 ] && exit 
pattern=$1 # pacchetto da installare
#################### RICERCA PACCHETTI E COSTRUZIONE ELENCO #################
# ricerca dei pacchetti conteneti il pattern di ricerca
# la ricerca coinvolgerà il campo NAME e LOCATION in modo
# da poterle abbinare per la successiva costruzione del link
# da passare a wget.
tmpdirpkg=/tmp/.tmpdir.pkg   # dir dove immettere il pacchetto provvisoriamente
[ -e $tmpdirpkg ] && rm -r $tmpdirpkg # se esistesse già la rimuove
mkdir $tmpdirpkg  # creo la directory che poi verrà eliminata: ospita i pacchetti
# i risultati vengono numerati e mostrati all'utente, in modo che possano essere
# scelti agevolmente, premendo il numero corrispondente e battendo invio
clear
cat <<EOM
PACCHETTI DISPONIBILI:
EOM
# crea un file acessorio in cui scrivere la lista greppata
# contenete package name e package location corrispondente.
# il file verrà creato sfruttando l'utility tempfile e sarà
# chiamato memorizzato nella variabile "tmp"
tmp=$(tempfile) # file accessorio contente lista greppata
# All'inizio della greppata di ogni file infilo una riga di 
# indicazione repo corrispondente: torna utile dopo
grep -A1 -i "^PACKAGE NAME:.*$pattern" ${cache[1]}/PACKAGES.TXT > $tmp
echo "REPO: SLACKY" >> $tmp
grep -A1 -i "^PACKAGE NAME:.*$pattern" ${cache[2]}/PACKAGES.TXT >> $tmp
echo "REPO: LINUXPACKAGES" >> $tmp
grep -A1 -i "^PACKAGE NAME:.*$pattern" ${cache[3]}/PACKAGES.TXT >> $tmp
# ora si lavorerà sul nuovo file, di più agile gestione
# si leggerà da quest'ultimo riga dopo riga...
i=0
v=0
ii=-111
reponum=1 # i pacchetti all'inizio del file sono quelli ufficiali
while read riga; do
        echo "$riga" |grep "^REPO: SLACKY$" > /dev/null
        [ $? -eq 0 ] && reponum=2
        echo "$riga" |grep "^REPO: LINUXPACKAGES$" > /dev/null
        [ $? -eq 0 ] && reponum=3
        echo "$riga" |grep "PACKAGE NAME" |grep -i $pattern > /dev/null
        if [ $? -eq 0 ]; then
             name[$v]=$(echo $riga |sed 's/PACKAGE NAME:[ ]*//') 
             ii=$[$i]
        fi
        if [ $i -eq  $[$ii+1] ]; then
             location[$v]=$(echo $riga |sed 's/PACKAGE LOCATION:[ ]*\.\///')
             prio[$v]=$reponum
             echo "$v   ${reponame[$reponum]}  ${name[$v]}      ${location[$v]}"
             v=$[$v+1]
        fi
        i=$[$i+1]
done < $tmp
####################### SCELTA DEL PACCHETTO ###########################
cat <<EOM
Scegli il pacchetto desiderato (premi il numero corrispondente)
EOM
read scelta
clear
cat <<EOM
HAI EFFETTUATO LA SCELTA SEGUENTE:
REPOSITORY:            ${reponame[${prio[$scelta]}]}
NOME PACCHETTO:        ${name[$scelta]}
LOCATION PACCHETTO:    ${location[$scelta]}
LINK COMPLETO: ${repo[${prio[$scelta]}]}/${location[$scelta]}/${name[$scelta]}
Vuoi scaricare il pacchetto?
EOM
conferma
clear
############ COSTRUZIONE LINK E DOWNLOAD DEL PACCHETTO ###################
# download del pacchetto in una directory "ad hoc":
urlpkg=${repo[${prio[$scelta]}]}/${location[$scelta]}/${name[$scelta]}
wget -c -P $tmpdirpkg $urlpkg
conferma
# permette un controllo all'utente di ciò che ha scaricato
clear
cat<<EOM
PACCHETTO SCARICATO:     $(ls $tmpdirpkg)
proseguo con l'aggiornamento/installazione?
EOM
conferma
clear
########### INSTALLAZIONE E PULIZIA DIRECTORY TEMPORANEE ##############
# installazione del pacchetto in questione
sudo upgradepkg --install-new $tmpdirpkg/*
# spostamento del tgz nella cache e rimozione delle dir temporanee
mv $tmpdirpkg/* ${cache[${prio[$scelta]}]}
rm -r $tmpdirpkg
######################## VERIFICA INSTALLAZIONE ##########################
# controllo pacchetto installato
cat <<EOM
CONTROLLO PRESENZA PACCHETTO......
$(ls /var/log/packages|grep -i $pattern)
EOM
-------------------------------------------------------------fine---
Bene gente, se qualcosa non funge fetevi vivi. Provatelo!!  ;-)