Slackbuilds

[goldy]

Era ora , mi viene in mente anche un mio vecchio post
che feci al riguardo proprio su slacky.
Lo avrà letto qualcuno di linuxpackages?

Anche se ho notato che ultimamente pure slacky.it
sta iniziando a fare in questo modo,
almeno nei pacchetti fatti dal bravissimo gohanz,
ci trovo gli slackbuild nella directory /usr/doc

Ma visto che siamo in argomento farei una richiesta
per modificare ulteriormente gli slackbuild,
almeno quelli di slacky

anzichè mettere

Codice: Seleziona tutto

cp -a *.SlackBuild
$PKG/usr/doc/$NAME-$VERSION

forse sarebbe meglio fare

Codice: Seleziona tutto

NAME=xxxx
VERSION=xxxx
PKG=$TMP/package-$NAME
SLACKBUILD=$NAME.SlackBuild

...................

cp $CWD/$SLACKBUILD $PKG/usr/doc/$NAME-$VERSION/slackbuild 

o in alternativa

cp $CWD/$SLACKBUILD $PKG/usr/src
come dice linuxpackages

c'è gente (come me) che magari in una directory
ha una valanga di slackbuid


e poi una volta che mettiamo lo slackbuild
sarebbe anche più elegante metterci
lo slack-desc

in questo modo

da

Codice: Seleziona tutto

cat $CWD/slack-desc > $PKG/install/slack-desc

a

Codice: Seleziona tutto

cat > $PKG/install/slack-desc <<EOF
          |-----handy-ruler------------------------------------------------------|
libcddb: LibCDDB
libcddb:
libcddb: Libcddb is a C library to access data on a CDDB server (freedb.org).
libcddb: It allows you to:
libcddb: search the database for possible CD matches;
libcddb: retrieve detailed information about a specific CD;
libcddb: submit new CD entries to the database.
libcddb:
libcddb:
libcddb:
libcddb:
EOF

Visto che mettiamo la pappa pronta
a questo punto la pappa la mettiamo pure già condita

[gallows]

Io già faccio:

Codice: Seleziona tutto

cp -a $CWD/slack-desc $CWD/$NAME.SlackBuild $PKG/usr/doc/$NAME-$VERSION

Per quanto riguarda lo slack-desc dentro lo SlackBuild mmm, non sarebbe male. Anche a me dà un po' fastidio avere 'sti slack-desc vaganti...
Al momento non mi vengono in mente "controindicazioni", comunque aspettiamo il parere di Loris.

Detto questo: ottima scelta quella di LP.

Ps. Inoltre i nostri pacchetti hanno lo slack-required creato da requiredbuilder

EDIT: Non so se qualcuno se ne è accorto, nei miei SlackBuild ho aggiunto un'opzione get_sources che scarica automaticamente i sorgenti del programma e altro (idea copiata da archlinux) sarebbe interessante implementarla anche negli altri Slackbuild... Potremmo fare una sistema di ports by Slacky.it

[gohanz]

Mi sembrano ottimi tutti i suggerimenti, ho appena finito di scrivere uno SlackBuild senza slack-desc esterno. :P

[Stabe]

Io personalmente sono contrario a una funzione stile get_sources, oppure a mettere gli slack-desc negli slackbuild, principalmente perchè gli SlackBuild sono già ottimi così come sono ora, anzì sono perfetti. Infatti fanno benissimo quello per cui sono stati predisposti: compilare e creare un pacchetto slackware dato tutto il necessario.

Per fare quello che intendete voi secondo me è meglio utilizzare un tool esterno piuttosto che aggiungere funzioni che vanno a "sporcare" gli slackbuild.

A questo scopo sto scrivendo un programmino in bash chiamato appunto slackbuilder, che a partire dal semplice albero dei sorgenti di slacky.it dovrebbe essere in grado di compilare tutti i pacchetti da sorgente creando ed eventualmente installando poi il pacchetto tgz.

In questo modo gli slackbuild restano puliti, anzi standard, e si ottengono molti più vantaggi.

Per il momento slackbuilder è ancora agli inizi e non funziona proprio benissimo, però spero nei prossimi mesi, o perlomeno durante l'estate, di terminarlo in tutte le funzioni fondamentali.

Inutile dire che gli slack-desc sono molto importanti perchè forniscono informazioni essenziali anche per il corretto funzionamento di requiredbuilder: grazie agli slack-desc requiredbuilder "indovina" il nome del pacchetto che si sta andando a creare e in questo modo riesce ad eliminarlo dalle dipendenze di se stesso.

[gallows]

Per lo slack-desc forse hai ragione, ma se vedi i miei SlackBuild sono pienamente standard, semplicemente c'è una funzione get_sources che viene invocata se non trova i sorgenti nella directory, es:
http://www.slacky.it/download/system/sl ... SlackBuild

[Stabe]

Ok così è già meglio :)
Comunque piuttosto a me piace di più l'idea di aggiungere un file di testo chiamato sources contenente il link per scaricare il tar.gz, eventulmente supportando anche le variabili dello slackbuild al suo interno.
Per esempio contenuto di sources per il pacchetto xxx:

http://www.xxx.org/downloads/$NAME-$VERSION.tar.gz

che ne pensi?

[gallows]

Beh sì, se guardi get_sources in pratica è quello:

Codice: Seleziona tutto

function get_sources() 
{
 wget http://download.berlios.de/slim/$TARBALL || exit 1
}

Dove TARBALL=$NAME-$VERSION.tar.gz

Solo che tenerlo in un file separato non fa che aumentare l'entropia IMHO.
Potremmo invece far supportare ai nostri SlackBuild una flag --get per attivare il download...
Alla fine sono procedure separate che non vanno ad interferire con le funzionalità classiche di uno SlackBuild.

[goldy]

Inutile dire che gli slack-desc sono molto importanti perchè forniscono informazioni essenziali anche per il corretto funzionamento di requiredbuilder:

ma perchè scusa requirebuilder dove va a cercare lo slack-desc?
immagino , anzi spero, nella directory install o sbaglio?
mica in $CWD

scrivendolo direttamente nello slackbuild
tecnicamente non cambia niente , poi
se mi sfugge qualcosa , gradirei volentieri
che mi sia fatto notare.

... gli SlackBuild sono già ottimi così come sono ora, anzì sono perfetti.

IMHO

sul lavoro che svolge lo script slackbuild
nulla da ridire , ma apportare qualche piccola
comodità all'utente, non credo sia nulla di rivoluzionario,
e soprattutto se non intacca minimamente la qualità stessa
degli slackbuild

[Stabe]

requiredbuilder non crea nessuno slack-desc, semplicemente se c'è lo sfrutta per ricavare il nome del pacchetto. Tutto qui.

Quello che dite voi ha certamente un senso.
Io però ritengo che sia meglio una soluzione che non appesantisca gli slackbuild, ma piuttosto sfrutti funzionalità\tool esterni.
Questo perchè gli slackbuild secondo me dovrebbero essere il più semplici possibile perchè così:

-sono più facili da scrivere

-sono più facili da mantenere

-sono più facili da capire e modificare da un esterno

io preferisco una soluzione che prevede "la logica" in un tool esterno piuttosto che aggiungere a TUTTI gli slackbuild (decine? centinaia?) una funzione come get_sources.
Poi al limite invece di scrivere un file sources si può decidere di mettere il link ai sorgenti in un variabile "standard" chiamata TARBALL all'interno degli slackbuild, ma sinceramente continuo a preferire il file sources :)
Anche perchè in quel caso sarebbe anche più facile inserire più link nel caso di più sorgenti.

[goldy]

Io però ritengo che sia meglio una soluzione che non appesantisca gli slackbuild, ma piuttosto sfrutti funzionalità\tool esterni.

Ecco , questo è già un punto di vista ben argomentato ,
ma qui però si tratta di cambiare troppe cose e snaturare
la gestione dei pacchetti di slackware ,
cosa che per la maggior parte degli utenti slackware,
che scelgono una distribuzione "conservatrice"
non credo sia vista di buon'occhio.

A questo punto tra scegliere di aggiungere un'altro programma ,
non ufficiale (non lo dimentichiamo) e mettere 3-4 righe di testo
in uno slackbuild come fatto da gallows , io personalmente
propenderei per la seconsa ipotesi

requiredbuilder non crea nessuno slack-desc, semplicemente se c'è lo sfrutta per ricavare il nome del pacchetto. Tutto qui.

Ma qui forse c'è una cosa che non'è chiara,
lo so che requirebuilder non crea il suddetto file
e nessuno ha mai detto di eliminare lo slack-desc,
la comodità della modifica che io avevo chiesto
potrebbe essere del tipo:

non sei costretto a creare una directory per ogni software
ma potresti benissimo avere una sola directory
con dentro sorgenti e slackbuild , senza sovrascrivere
gli slack-desc, una cosa comoda, sia per le directory
che hai nel computer locale o eventualmente di un sito web.

http://www.xxx.org/downloads/$NAME-$VERSION.tar.gz

Bel sito ma purtroppo non sono riuscito a scaricare niente

[Stabe]

Ecco , questo è già un punto di vista ben argomentato ,
ma qui però si tratta di cambiare troppe cose e snaturare
la gestione dei pacchetti di slackware ,
cosa che per la maggior parte degli utenti slackware,
che scelgono una distribuzione "conservatrice"
non credo sia vista di buon'occhio.

A questo punto tra scegliere di aggiungere un'altro programma ,
non ufficiale (non lo dimentichiamo) e mettere 3-4 righe di testo
in uno slackbuild come fatto da gallows , io personalmente
propenderei per la seconsa ipotesi

Chiaramente questa è più che altro una questione di "gusti" personali.
Tieni conto però che il programma non ufficiale sarebbe comunque in grado di interagire senza problemi anche con i sorgenti ufficiali.

non sei costretto a creare una directory per ogni software
ma potresti benissimo avere una sola directory
con dentro sorgenti e slackbuild , senza sovrascrivere
gli slack-desc, una cosa comoda, sia per le directory
che hai nel computer locale o eventualmente di un sito web.

visto che parli di standard e scelte conservative tieni conto che anche la struttura della directory "source" di Slackware è in qualche modo una standard, che, tra gli altri, viene seguito anche da Slacky.it, portpkg, Freerock GNOME.
Inoltre credo che l'organizzazione di source così com'è adesso, sia molto chiara e semplice anche da sfogliare manualmente da parte degli utenti, cosa che non si può dire nei confronti dei sorgenti dei pacchetti di molte alte distro.
Io non voirrei perdere una cosa del genere.