Slackware Package Manager

[amn]

Io credo che se si riuscisse a combinare qualcosa del tipo emerge/portage per Gentoo uscirebbe una bella cosa.

[Luke88]

ok... prendetevi mezz'oretta libera e un paio di aspirine, comincio ...

graz. amn per il link...
ho letto e penso di aver capito come funziona...
in pratica loro nei server tengono solo i file con all'interno le dipendenze e opzioni di config., i sorgenti vengono recuperati dai server del progetto.

l'idea non è male, ma penalizza l'utente che non vuole ricompilarsi il pacchetto, vuoi per il pc vecchio o vuoi per tempo o per altro... o almeno mi sembra, visto che non ho notato indicazioni di precompilati...
penalizza/elimina anche i repository creati per i pacchetti "con certe opzioni".
a meno che non si usi qualcosa tipo i flag USE, ma non saprei come gestirli, e anche gestendoli si perderebbero i repos precompilati "con particolari opzioni"... se sapete come gestirli si potrebbe usare il tutto, ma penso che sia sempre da fornire l'alternativa precompilato per lo stesso repository.

altrimenti...
per me la migliore è un ibrido...
ovvero la definizione di uno standard per la compilazione dei pacchetti...(tanto o tipo ebuild o così, qualcosa di nuovo salta fuori, ma questa mi sembra un po' più complicata forse, ma meno rivoluzionaria)
ovvero:
1-lo slackbuild si fa così e così (sembra una cavolata, ma ci sono differenze anche all'interno dello stesso repository sarebbe da discuterne con tutti, Pat soprattutto, e ricordarsi che non esiste solo make)
2-le dipendenze stanno in questo file (in perfetto stile slapt-get).

non servirebbe altro.
se vogliamo un qualcosa per diversificare (restando compatibili) un repos -ad esempio- slapt-get da uno $toll_futuro basterebbe copiare il file che descrive a quali pacchetti corrispondono quali librerie sul server con un nome definito, in modo da definirci meglio la fase di modifica slackbuild per ricompilazione..(vedi dopo)

questo sarebbe utile anche per un fallback: se il server delle dipendenze non è up, usa il file del repos...o per diversificare le dipendenze dei tgz di uno stesso programma in diversi repository.... così manteniamo sia le dipendenze minime che quelle derivate da specifiche opzioni di compilazione...

qualcosa tipo:
nome
dipendenza-minima1
nome@repos
dipendenza-aggiunta1

per "dipendenza minima" indico il minimo possibile, togliendo ogni opzione tramite ./configure o chi per lui.

questo è fattibile anche negli slack-required penso...bisogna vedere come sono gestiti da slapt-get...potrebbe diventare:
##nome
dipendenza1
##option
dipendenza2

così slapt-get lo vede tranquillamente (la parte da lui non capibile è commentata) e noi abbiamo il doppio-dipendenza
così possiamo gestirci la meglio la parte di ricompilazione per le dipendenze.

il problema sarebbe diffonderlo, ma se il tool si rivela all'altezza, poi sarà più facile. e poi questo problema c'è anche per roba tipo emerge, a meno di non usare i loro stessi ebuild... ma a questo punto diamo una mano/facciamo un fork di emerde, no?


questo renderebbe tutto più semplice. per la ricompilazione e modifica ./configure basterebbero un paio di sed sullo slackbuildi senza seghe mentali, le dipendenze le abbiamo già...

si può fare già adesso semplicemente modificando lo slackbuild presente, e sfruttando gli slack-required di slapt-get, ma prima bisognerebbe prendere una buona quantità di slackbuild per vedere quali sono le differenze... avevo provato a vedere, e -per dirne una- l'arch a volte è messo ARCH="i686", altre ARCH=${ARCH:-i686}, altre non è specificato se non al momento dell'uso... insomma, non impossibile da aggirare, ma senza standard è più difficile e sporco

per ora potremmo creare qualcosa che controlli se il repos è compatibile; in caso negativo modifica lo slackbuild in modo sporco magari, ma che funzioni, in caso positivo lo modifica con un paio di sed, così il tutto resta pulito. questo è utile a qualcuno che si voglia tenere lo slackbuild...(qui ci mettiamo una possibilità di salvataggio/eliminazione di slackbuild e pacchetto? magari dal file di config?)



inoltre così non pretendiamo che qualcuno come Loris si gestisca 30 repository, uno per tool supportato, manteniamo la diversificazione tra repository e daremo più importanza allo slack-required, dando come motivo oltre a slapt-get anche questo tool...

per il discorso dipendenze io mi butterei sul tool di absinthe magari gli diamo una mano per l'integrazione di alcune feature tipo il link libreria=pacchetto... poi possiamo impostare un fallback: se il pacchetto indicato da slck-required corrispondente alla libreria non è installato, facciamo la ricerca contraria, ovvero cerca le librerie/file (quali? da definire... può essere un eseguibile o una libreria...) che quel pacchetto-required installa e controlla se sono già installate (c'è il problema del path anche però... risolvibile comunque...).
in caso positivo avverti il tipo che c'è la libreria-dipendenza, ma non siamo sicuri che il software funzionerà (a volte non basta la libreria).
il tutto recurivo, ovvio.

ci riuscite a capire qualcosa? ho provato a renderlo semplice il discorso, ma più di così è difficile per me...

siccome qualsiasi cosa facciamo è da definire, propongo di nominare un referente per le modifiche/definizioni... qualcuno che abbia tempo libero... io propongo amn -anche perchè il thread l'ha tirato fuori lui -

[amn]

Ma guarda che questo tool non sara` come emerge nel senso che si scarica sempre i sorgenti e si mette a compilare.
Si scarica i pacchetti tgz per slackware da mirror ufficiali, tipo slackware.it e li installa.
Poi si potrebbe anche aggiungere l'opzione per decidere se farglielo installare dai sorgenti manualmente o se installare il pacchetto.
Il problema e` che ogni utente Gentoo ha una directory (/usr/portage/) dove ci sono tutti gli ebuild, e sono veramente tanti,
quindi non so se fare una cosa del genere, un pacchetto dove mettere tutti gli ebuild da far prendere ad ogni utente
che vuole usare questo tool, o se metterli tutti su un server, cosi` il tool andrebbe a cercare li`.

[absinthe]

per come la vedo: gestire precompilati è + semplice che gestire sorgenti. se uno vuol provare meglio partire da lì. se poi le cose funzionaeno si può passare alla gestione dei sorgenti!

M

PS: vedo che la cosa piace a molti... e meno male che ci piace slack

[amn]

PS: vedo che la cosa piace a molti... e meno male che ci piace slack

Be` certo, secondo me, slackware con un buon tool che gestisse queste cose, (e non uno come i tanti che ci sono) sarebbe perfetta.
Alla fine, (secondo me) l'unica pecca di Slackware e` proprio questa.
Per il resto posso dire che e` perfetta.

[IceSlack]

mah non c'e' gia' emerde?

[amn]

mah non c'e' gia' emerde?

sento un sacco di gente che appena ha messo emerde gli ha sputtanato tutta le librerie eccetera,
mi sembra che uno di quelli sia l1q1d, sbaglio?

[conqueror]

mah non c'e' gia' emerde?

sento un sacco di gente che appena ha messo emerde gli ha sputtanato tutta le librerie eccetera,
mi sembra che uno di quelli sia l1q1d, sbaglio?

pure a me!!! Mannaggia a emerde (per non dire altro....), infatti mi ha sputtanato molte cose, e sto aspettando trepidante l'uscita della 11 anche perchè approfitto per sistemare le partizioni!!!

[IceSlack]

mah non c'e' gia' emerde?

sento un sacco di gente che appena ha messo emerde gli ha sputtanato tutta le librerie eccetera,
mi sembra che uno di quelli sia l1q1d, sbaglio?

pure a me!!! Mannaggia a emerde (per non dire altro....), infatti mi ha sputtanato molte cose, e sto aspettando trepidante l'uscita della 11 anche perchè approfitto per sistemare le partizioni!!!

gia'... osnos enza slack da 1 mese e passa

[amn]

Aspetteremo ancora molto!
Uffa pero`, che lentezza.

Patrick aveva detto:

I wasn't planning a Slackware 11.0 release candidate 4, but here we go.

E ora sta preparando la RC5, lol.

[CiccioPalla]

Ciao a tutti,
volevo spendere i miei due cents.

Ho letto con molto interesse (e molta speranza ) la discussione, anche se sono stupito dalla complessità che sembra avere assunto il problema.
In fondo ci sono già tante soluzioni, più o meno valide (apt-get su tutti), perchè non copiarne i concetti base?

per le dipendenze mi domandavo se non potesse bastare qualcosa come un file chiamato ad es.

nomeprogramma-versione.dep

e che all'interno possa avere una struttura tipo

Codice: Seleziona tutto

[required]
nomepacchetto;versione
nomepacchetto1;versione
[optional]
nomepacchetto2;versione
nomepacchetto3;versione

L'ultilità di questo approccio secondo me, sta nella sua intrinseca semplicità, che porta a diversi vantaggi, tra cui:

1)Non dipenderemmo da script bash: niente script "esoterici" e sintassi assurde...
(de gustibus... )

2)"capire" le dipendenze sarebbe un compito semplice, per un uomo e per un software (che potrebbe essere scritto in qualsiasi linguaggio, quindi non saremmo legati ad un solo software)

3)si potrebbe coinvolgere un numero maggiore di utenti, magari spingendoli ad "adottare" un software e mandare al rep. i file con le dipendenze

4)non ci sarebbero da modificare i pacchetti già esistenti, ma ci potrebbero essere dei rep a parte, facilmente replicabili (e che occuperebbero anche poco spazio, quindi mirror più piccoli)

.....dove sbaglio?

A.

[clodo]

Inanzitutto apt-get non risolve le dipendeze

x chroot:
ma stai parlando di apt-get di debian?

[masalapianta]

Inanzitutto apt-get non risolve le dipendeze,quindi un gestore come quello meglio perderlo che trovarlo

ROTFL! sei una sagoma, ora pero' torna a usare i ports (rotfl)

[clodo]

Inanzitutto apt-get non risolve le dipendeze,quindi un gestore come quello meglio perderlo che trovarlo

Tengo ha precisare che ho solamente detto la mia,ultimamente vegno frainteso,e non mi va bene la cosa,io sono affabile con tutti e non e da me litigare ..

Beh, anche non volendo fraintendere, cioè prendendo alla lettera ciò che hai scritto, è dura non "discutere"....

[lennynero]

raga mi son letto un pò il 3d, ma mi sono rimate delle lacune, forse xke ogni tanto mi distraevo o xke ci sono delle dissertazioni un pò criptiche(ho detto forse ), comunque passiamo a noi, innanzitutto non ho capito bene a cosa serve slack-required, lo usa solo slapt-get?è uno standard?come mai sta nei pacchetti di slacky e di linuxpackages(credo) ma non in quelli ufficiali?(forse le 3 domande hanno una sola risposta); poi vorrei chiedere, mantenendomi sempre sui precompilati(concordo con absinthe che bisogna concentrarsi prima su quelli), se io compilo un prog con particolari flags(nel configure) come posso farlo sapere ad un eventuale utilizzatore del mio pacchetto?in sostanza per me servirebbe uno slack-config (so che aggiunere roba nel pacchetto non è la migliore delle idee) in modo che uno user prima di installare il pacchetto sa che ha quelle caratteristiche, o magari può cercare il pacchetto con quelle caratteristiche, qui interviene l'implementazione di un tool ex-novo che sappia gestire questa cosa(tipo che mi mostra la lista delle dipendenze ddi slack-required, e le opzioni con sui è stato compilato il pacchetto con slack-config).
Magari ho detto qualche baggaianata, illuminatemi meglio su questo gap delle dipendenze e xke non è sufficiente slack-required, magari si propone di tenerlo non integrato nel pacchetto ma come file sul repository(ho capito bene?). Insomma uno interroga il repository, riceve lo slack-required, il tool informa e opzionalmente installa le dipendenze. Questo tool non mi sembra apocalittico in bash(anche se io sono davvero un niubbo), mi rendo comunque disponibile per qualche collaborazione...Ah il problema è riempire lo slack-required(compilati e non) insomma?(requiredbuilder risolve anche perl...) o forse il problema è proprio gestire il/i repository?

Io nel frattempo mi arrangio così:
1 o scarico pacchetti da slacky con swaret che mi risolve dipendenze;
2 o mi creo pacchetti dai sorgenti con un mio script (e riempio lo slack-required a posteriori(non sapevo dell'esistenza di ldd...provvederò)) per eventuale utilizzo con slapt-get(che proverò)
3 ...il resto dei tool di cui ho bisogno stanno nel cd di slack
4 leggendo il 3d ho trovato questo: http://www.stabellini.net/depslack.html(come idea non è male, magari sarebbe meglio + modulare, automatizzata ovviamente(il lavoro starebbe nello scovarle queste !benedette dipendenze )

ps io ho citato slack-required perchè l'ho trovato nei pacchetti di slacky e nel manuale "the perfect package" di linuxpackages...
pps mamma mia mille domande, il mio prof direbbe che è positivo, bè in realtà mi interessa l'argomento, non aggiorno tanto di continuo, ma mi rendo conto aumenterebbe la qualità dell'environment "Slackware"