Slackware Package Manager

[amn]

Bene ma, qualcuno ha un sito o un qualcosa dove posso trovare per ogni pacchetto tutte le sue dipendenze?
Il repository di slacky e' un buon inizio con gli slack-requires.

[l1q1d]

Per il discorso binario/compilazione swaret lo fa già: install (cerca il binario e lo installa), compile scarica i sorgenti e lo slack-build e compila.

Per quanto riguarda il linguaggio io mi orienterei su un programma che non bisogna compilare quindi bash o python.

Per quanto riguarda le dipendenze secondo me la cosa più utile è inserire nel pacchetto lo slack-required.

[amn]

Per quanto riguarda le dipendenze secondo me la cosa più utile è inserire nel pacchetto lo slack-required.

si ma sai che vuol dire rifare tutti i pacchetti inserendoci lo slack-required
ma scusa l1q1d, alla fine, non e` la stessa cosa? Il tool andrebbe a cercare degli "slack-requires"
su un sito, dopodiche` procede.. boh, ditemi voi

[absinthe]

Per quanto riguarda le dipendenze secondo me la cosa più utile è inserire nel pacchetto lo slack-required.

si ma sai che vuol dire rifare tutti i pacchetti inserendoci lo slack-required
ma scusa l1q1d, alla fine, non e` la stessa cosa? Il tool andrebbe a cercare degli "slack-requires"
su un sito, dopodiche` procede.. boh, ditemi voi

basterebbe che lo slack-required fosse rinominato come il tgz: es. banale:

hydrogen-0.9.3-i486-1sl.tgz <-- file tgz
hydrogen-0.9.3-i486-1sl.sr <-- file slack-required

così non si può sbagliare divverrebbe specifico del programma della versione dell'architettura e del build!

M

PS: concordo con il linguaggio interpretato: secondo me meglio bash di python. sarebbe molto più usabile visto che non tutti installano python mentre è obbligatorio avere bash (non proprio, volendo uno usa un'altra shell ma anche i pkgtool mi pare siano in bash...)

[l1q1d]

Il problema è che se il server è down o non esiste sul server quel pacchetto uno deve risolverle a mano e siccome con swaret non funziona.l
L'idea di mettere un file aggiuntivo non è niente male.

[amn]

Il problema è che se il server è down o non esiste sul server quel pacchetto uno deve risolverle a mano e siccome con swaret non funziona.l
L'idea di mettere un file aggiuntivo non è niente male.

Ci sarebbero piu` server anche inizialmente.
Quello principale, sourceforge, e altri come hosting del progetto.
Comunque, riguardo il file aggiuntivo.. vabbe` ma che si puo` fare?
Dite di mettere sul mio server un file chiamato in quel modo che contenga le dipendenze?
Non sarebbe male come idea, ma ogni volta dovrei aggiornare le versioni.
Il che rende il tutto pesante. Pensavo ad un controllo automatico delle versioni, comunque si puo` sempre vedere,
magari con l'aiuto di collaboratori specifici in questo.

[absinthe]

Il problema è che se il server è down o non esiste sul server quel pacchetto uno deve risolverle a mano e siccome con swaret non funziona.l
L'idea di mettere un file aggiuntivo non è niente male.

non ho capito molto bene il problema di swaret.. potresti spiegare?

M

[l1q1d]

Swaret fa un ldd dei file e poi va su:
101 DEP_ROOT=http://www.swaret.org/swaret
102 DEP_ROOT=ftp://ftp.swaret.org/swaret
e cerca di risolvere i pacchetti il problema è che non tutti i pacchetti sono indicizzati, ma solo le librerie più comuni, di conseguenza non riesce sempre a risolvere le dipendenze.

[absinthe]

Il problema è che se il server è down o non esiste sul server quel pacchetto uno deve risolverle a mano e siccome con swaret non funziona.l
L'idea di mettere un file aggiuntivo non è niente male.

Ci sarebbero piu` server anche inizialmente.
Quello principale, sourceforge, e altri come hosting del progetto.
Comunque, riguardo il file aggiuntivo.. vabbe` ma che si puo` fare?
Dite di mettere sul mio server un file chiamato in quel modo che contenga le dipendenze?
Non sarebbe male come idea, ma ogni volta dovrei aggiornare le versioni.
Il che rende il tutto pesante. Pensavo ad un controllo automatico delle versioni, comunque si puo` sempre vedere,
magari con l'aiuto di collaboratori specifici in questo.

purtroppo è l'unico modo per essere sicuri: metti che slacky hosti un tgz di amarok-2.4 (es) con certe opzioni abilitate in compilazione (e quindi dipendenze) e che linuxpackages abbia un tgz di amarok-2.4 con altre opzioni: nascerebbe un casino: a quasto punto il $BUILD definirebbe in maniera univoca (oddio direi che è un problema probabilistico... però è relativamente sicuro) il tgz con le dipendenze.
per l'update dei files: i files possono essere parzioalmente costruiti in automatico ma richiedono comunque una revisione a mano -specie per le dipendenze logiche o per i programmi interpretati e non compilati-: è inevitabilmente un lavoro enorme: sicuramente più rapido che spacchettare itgz e inserire dentro il file (e anche moeno oneroso come spazio richiesto sull'host).
per il problema del server down (mi ricollego a l1q1d): ogni repository che si rispetti contiene un file chiamato FILELIST.TXT o simile contenente l'equivalente di un 'find .' eseguito sulla directory di root del repository: basterebbe fare una copia locale della lista dei file (una sorta di slapt-get --update o quello che vi pare) per sapere se esiste un file per le dipendenze: in assenza di esso o in caso di irraggiungibilità uno si risolve a manina le dipendenze credo...

M

PS: discussione stimolante

[l1q1d]

La mia idea sul funzionamento:
ricerca programma:
scelta tipo pacchetto 1 -> Binario
2 -> Sorgenti
Se 1 allora va nel repository cerca il pacchetto e scarica la lista delle dipendenze (che potrebbero essere all'interno o in un altro file), chiede se si vuole scaricare e se si vogliono scaricare le dipendenze. Scarica e installa cio che è stato selezionato dall'utente.
Se 2 scarica i sorgenti e lo slackbuild e compila creando il pacchetto e installandolo.

Il problema è come mettere le dipendenze:
elenco pacchetti con cui è stato compilato o librerie di cui ha bisogno?

[amn]

Uhm.. un po` di confusione..
Per ricapitolare absinthe e l1q1d (che per ora siete quelli che hanno maggiormente discusso qui), facendo un piccolo elenco, cosa dovrebbe fare/avere questo tool?
Cosi per mettere un po` a posto. Io avevo pensato a:
tool
-------> --- quando si lancia il comando per installare --- ---->

--------> ---- ricerca il pacchetto attraverso un "filelist" su un server mio --- --------->

---------> ---- il tool viene indirizzato sui vari mirror, ufficiali e non --- --------->

----------> ----- installazione del pacchetto attraverso installpkg ----- ------------>

[da decidere]
----------> --- il tool puo' ricercare dei file un un server mio (e non), tipo degli slack-requires --- ----->

-------> --- il tool puo' ricercare all'interno del pacchetto che si installa lo slack-requires --- ---------> # questo vorrebbe dire inserire un sacco di file in un repository
[/da decidere]

--------> recupero dipendenze e installazione di quest'ultime <------------

Allora?

[l1q1d]

l'alternativa è creare un buon tool che dal pacchetto compilato riesca ad estrarre le dipendenze

[amn]

uhm.. intendi uno che ad esempio, installa il pacchetto principale, prova ad avviare il software,
se non va per la mancanza di alcune librerie, prende il nome della libreria e la scarica, e cosi
via finche` il software non parte. Ma sarebbe un po`.. brutto.
Credo non sarebbe bello far partire il programma per vedere che librerie mancano.

[l1q1d]

Non serve mica farlo partire per sapere cosa manca basta ldd. solo che bisogna migliorare il sistema per trovare il pacchetto di appartenenza

[amn]

Si hai proprio ragione, sarebbe una buona idea, non resta che decidere quale delle tre sia piu' appropriata.
L'ultima non sembra male pero'..
Avanti, secondo voi qual e` la migliore delle tre? Per te L1q1d?

Ricordatevi che questo sarebbe solo il funzionamento per l'installazione di un pacchetto, poi dovro` vedere per creare un potente e sicuro sistema di aggiornamento, rimozione eccetera.