Domande ai Packager (e slackbuild di prova)

Postate qui se avete consigli per migliorare i pacchetti disponibili in questo sito o se avete problemi con installazione, funzionamento o altro.

Moderatore: Staff

Regole del forum
1) Citare in modo preciso il nome del pacchetto.
2) Specificare se discussione/suggerimento o richiesta d'aiuto.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.

La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
Avatar utente
Thraphyx
Linux 2.x
Linux 2.x
Messaggi: 212
Iscritto il: ven 28 ago 2009, 22:43
Slackware: 14.1 multilib
Kernel: 3.10.17
Desktop: KDE 4.11.5

Domande ai Packager (e slackbuild di prova)

Messaggio da Thraphyx »

Salve a tutti!
Probabilmente molti di voi staranno guardando la partita dell'Italia, ma a me poco interessa e scrivo sul forum :D!
L'argomento è gia stato trattato qui, ma vorrei comunque approfondire alcuni dettagli. Di che sto parlando? Ma del mestiere del packager, ovviamente!
Ebbene, dopo tante soddisfazioni che mi ha regalato la Slackware, e l'immenso aiuto che ho ricevuto da voi, soprattutto con la presenza del repository, sento che è arrivato il momento di ricambiare il favore. So che ogni volta che esce una nuova stable, c'è bisogno di ricompilare tutto, e oltretutto con il nuovo repo a 64 bit il lavoro posso immaginare sia aumentato ancora.
Per questo, mi piacerebbe contribuire alla creazione dei pacchetti per il repository!
Ho in programma di installare una 13.1 a 64 bit a breve, quindi presumibilmente mi concentrerò sui pacchetti per questa architettura, ma volendo si può anche compilare a 32 bit !
Per ora sono ancora sulla 13.0 a 32 bit.

Bene, dopo quest'introduzione, vorrei chiedere (soprattutto ai packager) qualche informazione e qualche consiglio, prima di fare richiesta ufficiale a Loris :D.

Fin'ora ho compilato vari pacchetti, prendendo gli scripts da slackbuilds.org. Ovviamente modificando dove opportuno il codice. Oggi però, volendo provare un player audio, DeaDBeef, ho deciso di scrivere lo script seguendo le direttive sul wiki (quindi con una struttura abbastanza standard, controllo delle dipendenze, download del source direttamente dallo script, etc..).
Ebbene, lo script è riuscito, e il pacchetto anche! \:D/
Però ho fatto una modifica al template che riguarda lo slack-desc e il doinst.sh.
In pratica li faccio generare dallo stesso slackbuild, così:

Codice: Seleziona tutto

if [ ! -e $CWD/slack-desc ]; then
	cat > $CWD/slack-desc << "EOF"
QUESTO È LO
SLACK-DESC
EOF
fi

if [ ! -e $CWD/doinst.sh ]; then
		cat > $CWD/doinst.sh << "EOF"
QUESTO È IL
DOINST.SH
EOF
fi
Li salva nella directory dello slackbuild, il quale poi provvederà a copiarli nella directory della documentazione.
In questo modo non serve scaricarli per creare il pacchetto, ma basta lo slackbuild.
Che ne dite? Si può fare o devo attenermi al template?

Poi vorrei qualche informazione in merito alla gestione dei pacchetti.
  • Come vengono gestiti gli aggiornamenti dei vari software? Appena esce una nuova versione si aggiorna, si aspetta, insomma che politica bisogna seguire?
  • Come compilate? Installazione principale oppure macchina virtuale/chroot? (io sarei orientato sulla seconda opzione)
  • Quanto testate i pacchetti prima di metterli nel repo?
Per ora è tutto :p .
Chiedo scusa per il post lunghissimo, ma spero che qualche anima volenterosa possa darmi qualche risposta! :o
Se avete letto fin qui, grazie per l'attenzione!
Thraphyx

PS. Allego lo slackbuild che ho scritto, magari a qualcuno può servire. Potete anche provare a cancellare gli altri file oltre lo slackbuild, tanto ci pensa lo script a crearli
Allegati
deadbeef-0.4.1.tar.gz
(2.65 KiB) Scaricato 44 volte
Ultima modifica di Thraphyx il dom 11 lug 2010, 16:55, modificato 2 volte in totale.

Avatar utente
Ansa89
Iper Master
Iper Master
Messaggi: 2703
Iscritto il: mer 29 ago 2007, 17:57
Nome Cognome: Stefano Ansaloni
Slackware: 14.2 64bit
Kernel: 4.9.61
Desktop: XFCE 4.12
Località: Modena

Re: Domande ai Packager (e slackbuild di prova)

Messaggio da Ansa89 »

Io parlo da esterno: secondo me puoi mettere una condizione per controllare se c'è (ad esempio) lo "slack-desc" e agire di conseguenza:

Codice: Seleziona tutto

if [ -e $CWD/slack-desc ]; then
  cat $CWD/slack-desc > bla/bla
else
  cat > slack-desc << "EOF"
  bla bla
  EOF
fi
[ EDIT: mi accorgo adesso che ho scritto la stessa cosa che hai scritto tu, quindi mi trovo d'accordo con la tua idea :) . ]

Per il discorso "aggiornamenti", penso che tu posso decidere: o aspetti che un utente segnali la nuova versione con pkgreports, oppure stai attento e appena vedi la nuova release la pacchettizzi.
La compilazione è da eseguire su una slackware vergine, con gli security fix installati (nessun altro pacchetto/programma aggiuntivo è concesso).
Il testing viene fatto principalmente dagli utenti finali (credo), comunque se sei scrupoloso puoi farlo direttamente tu.

Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5441
Iscritto il: ven 2 giu 2006, 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

Re: Domande ai Packager (e slackbuild di prova)

Messaggio da ZeroUno »

Thraphyx hai indovinato, c'è molto lavoro.

In occasione della slackware 13.1 abbiamo stilato quelle linee guida da dove hai tratto lo SlackBuild.
Abbiamo parlato di tante cose, ma su una cosa siamo stati fermi... finchè non ce n'è vera necessità tutti i file restano esterni allo SlackBuild.
Uno dei casi di necessità è quando uno script di postinstallazione che devi lanciare non sai a priori dove si trova. Per esempo se il mio programma deve lanciare lo script
/usr/lib/myprog/postinstall.sh
è chiaro che prima di lanciare lo slackbuild non so se questo si troverà in /usr/lib o /usr/lib64, allora, dentro lo slackbuild, si mette

Codice: Seleziona tutto

echo "( cd usr/lib$LIBDIRSUFFIX/myprog; ./postinstall.sh )" >> install/doinst.sh
il doinst, in ogni caso, non viene creato dentro la directory dello slackbuild ma esclusivamente dentro la directory install/ del pacchetto.

Lo slack-required è l'unico file che viene messo sia in install sia nella directory dello SB.

Per quanto riguarda il testing del pacchetto, si spera che il pacchettizzatore carichi pacchetti che lui stesso abbia testato. A meno che qualcuno non abbia dubbi, allora prima di caricare chiede se qualcuno gli da una mano a capire se c'è un problema.

Per quanto riguarda la distribuzione deve essere vanilla con le patch installate.
Se sai per certo che il tuo programma preferito non da fastidio ad eventuali pacchetti che vuoi compilare, te lo puoi anche installare. Per esempio è difficile che openoffice vada ad infilarsi nelle dipendenze di compilazione di unrar. Problemi invece potrebbe dare il gcc multilib di alien.
La current invece è vietata.

Il consiglio maggiore è il chroot.
Personalmente uso una current-64bit come uso abituale, una 13.1-64bit per compilare i pacchetti a 64bit e una 13.1-32bit chrootata per i pacchetti a 32bit.
Ovviamente va installato requiredbuilder.

Per l'aggiornamento, ok come dice Ansa89, se ti accorgi dell'uscita di una nuova versione oppure se te lo segnalano.

un'altra cosa. se alleghi il tar.gz di molti file, mettili in una directory:

Codice: Seleziona tutto

# mkdir deadbeef
# mv deadbeef.SlackBuild slack-desc slack-required doinst.sh deadbeef/
# tar cf deadbeef-0.4.1.tar.gz deadbeef
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

Avatar utente
Thraphyx
Linux 2.x
Linux 2.x
Messaggi: 212
Iscritto il: ven 28 ago 2009, 22:43
Slackware: 14.1 multilib
Kernel: 3.10.17
Desktop: KDE 4.11.5

Re: Domande ai Packager (e slackbuild di prova)

Messaggio da Thraphyx »

Rapidissimi! :D
Allora, veniamo a noi

ZeroUno ha scritto: finchè non ce n'è vera necessità tutti i file restano esterni allo SlackBuild.
Uno dei casi di necessità è quando uno script di postinstallazione che devi lanciare non sai a priori dove si trova. Per esempo se il mio programma deve lanciare lo script
/usr/lib/myprog/postinstall.sh
è chiaro che prima di lanciare lo slackbuild non so se questo si troverà in /usr/lib o /usr/lib64, allora, dentro lo slackbuild, si mette

Codice: Seleziona tutto

echo "( cd usr/lib$LIBDIRSUFFIX/myprog; ./postinstall.sh )" >> install/doinst.sh
Ah, ok.. quindi il doinst.sh e lo slack-desc bisogna crearli esterni, anche se.. Che problemi ci sarebbero scrivendo direttamente dallo SB il doinst.sh, visto che poi l'eventuale script post-install può essere aggiunto con quel comando tranquillamente dopo aver creato il doinst.sh? Ovviamente se bisogna fare così si fa, ma è giusto per capire :D
il doinst, in ogni caso, non viene creato dentro la directory dello slackbuild ma esclusivamente dentro la directory install/ del pacchetto.
....
Lo slack-required è l'unico file che viene messo sia in install sia nella directory dello SB.
...
Io pensavo che bisognasse anche crearlo "a parte", visto che nel repo le directory src/ contengono oltre allo slackbuild anche il doinst.sh, lo slack-desc e lo slack-required appunto. E quindi per poter caricare tutto bisogna crearli... no? :-k
Per quanto riguarda il testing del pacchetto, si spera che il pacchettizzatore carichi pacchetti che lui stesso abbia testato. A meno che qualcuno non abbia dubbi, allora prima di caricare chiede se qualcuno gli da una mano a capire se c'è un problema.
Ok
Per quanto riguarda la distribuzione deve essere vanilla con le patch installate.
Se sai per certo che il tuo programma preferito non da fastidio ad eventuali pacchetti che vuoi compilare, te lo puoi anche installare.
Si, sapevo dovesse essere vanilla, come ha anche gia detto Ansa89. Ma ovviamente se un pacchetto richiede dipendenze non-ufficiali, le si compila no?
E se un pacchetto richiedesse ad esempio una libreria più recente di quella ufficiale presente nella slackware, si ricompila, si installa e si crea il pacchetto? E dopo la si deve rimuovere per non inficiare su altre compilazioni?
Il consiglio maggiore è il chroot.
Personalmente uso una current-64bit come uso abituale, una 13.1-64bit per compilare i pacchetti a 64bit e una 13.1-32bit chrootata per i pacchetti a 32bit.
Ovviamente va installato requiredbuilder.
Ok, come immaginavo, ma che differenze ci sono rispetto a una macchina virtuale? Posso presumere che si consumino meno risorse durante la compilazione, giusto?
Ansa89 ha scritto: Per il discorso "aggiornamenti", penso che tu posso decidere: o aspetti che un utente segnali la nuova versione con pkgreports, oppure stai attento e appena vedi la nuova release la pacchettizzi.
Apposto :thumbright:

Scusate, un'altra domanda..
Usando gli SB di slackbuilds.org, prendevo i file, cambiavo qualcosa e lanciavo lo script. Ora creandone uno da me, ho prima installato il software con i classici ./configure&&make&&make install in /usr/local, per sapere eventualmente che opzioni passare al ./configure, e soprattutto per vedere quali file venivano creati e agire di conseguenza (tipo con la documentazione)..
È un approccio corretto? Voi come vi comportate?

Lo so, alcune domande potrebbero sembrarvi banali, ma voglio essere sicuro di quello che faccio.
Grazie davvero per l'aiuto :thumbright: :thumbright:

PS. ZeroUno, hai ragione, mi sono dimenticato proprio di mettere tutti i file in una directory! Me lo ricorderò

Avatar utente
Ansa89
Iper Master
Iper Master
Messaggi: 2703
Iscritto il: mer 29 ago 2007, 17:57
Nome Cognome: Stefano Ansaloni
Slackware: 14.2 64bit
Kernel: 4.9.61
Desktop: XFCE 4.12
Località: Modena

Re: Domande ai Packager (e slackbuild di prova)

Messaggio da Ansa89 »

Thraphyx ha scritto:Si, sapevo dovesse essere vanilla, come ha anche gia detto Ansa89. Ma ovviamente se un pacchetto richiede dipendenze non-ufficiali, le si compila no?
E se un pacchetto richiedesse ad esempio una libreria più recente di quella ufficiale presente nella slackware, si ricompila, si installa e si crea il pacchetto? E dopo la si deve rimuovere per non inficiare su altre compilazioni?
Ovviamente devi avere installate tutte le dipendenze richieste dal programma che stai compilando.
In seguito va rimosso tutto per riavere la slack pulita.
Thraphyx ha scritto:
Il consiglio maggiore è il chroot.
Personalmente uso una current-64bit come uso abituale, una 13.1-64bit per compilare i pacchetti a 64bit e una 13.1-32bit chrootata per i pacchetti a 32bit.
Ovviamente va installato requiredbuilder.
Ok, come immaginavo, ma che differenze ci sono rispetto a una macchina virtuale? Posso presumere che si consumino meno risorse durante la compilazione, giusto?
Come hai giustamente detto: la macchina virtuale richiede molte più risorse (ram/cpu) rispetto a chroot.
Thraphyx ha scritto:Scusate, un'altra domanda..
Usando gli SB di slackbuilds.org, prendevo i file, cambiavo qualcosa e lanciavo lo script. Ora creandone uno da me, ho prima installato il software con i classici ./configure&&make&&make install in /usr/local, per sapere eventualmente che opzioni passare al ./configure, e soprattutto per vedere quali file venivano creati e agire di conseguenza (tipo con la documentazione)..
È un approccio corretto? Voi come vi comportate?
Per vedere che opzioni passare a "./configure" (e in generale come strutturare uno slackbuild) prendi uno slackbuild da slacky.eu.
In generale ti posso dire che non ho mai visto usare "/usr/local" come prefix (di solito si usa "--prefix=/usr")
Thraphyx ha scritto:Lo so, alcune domande potrebbero sembrarvi banali, ma voglio essere sicuro di quello che faccio.
Chiedere è sempre lecito (se non va contro il regolamento).

Avatar utente
conraid
Staff
Staff
Messaggi: 13630
Iscritto il: gio 14 lug 2005, 0:00
Nome Cognome: Corrado Franco
Slackware: current64
Desktop: kde
Località: Livorno
Contatta:

Re: Domande ai Packager (e slackbuild di prova)

Messaggio da conraid »

Ansa89 ha scritto:
Thraphyx ha scritto:Si, sapevo dovesse essere vanilla, come ha anche gia detto Ansa89. Ma ovviamente se un pacchetto richiede dipendenze non-ufficiali, le si compila no?
E se un pacchetto richiedesse ad esempio una libreria più recente di quella ufficiale presente nella slackware, si ricompila, si installa e si crea il pacchetto? E dopo la si deve rimuovere per non inficiare su altre compilazioni?
Ovviamente devi avere installate tutte le dipendenze richieste dal programma che stai compilando.
In seguito va rimosso tutto per riavere la slack pulita.
veramente la linea è sempre stata quella di lasciare le librerie di default, se il programma richiede una libreria aggiornata significa che non è per la stable.
A meno di casi particolari quindi si lascia l'ultima versione compilabile sulla stable

Avatar utente
Ansa89
Iper Master
Iper Master
Messaggi: 2703
Iscritto il: mer 29 ago 2007, 17:57
Nome Cognome: Stefano Ansaloni
Slackware: 14.2 64bit
Kernel: 4.9.61
Desktop: XFCE 4.12
Località: Modena

Re: Domande ai Packager (e slackbuild di prova)

Messaggio da Ansa89 »

Mi sono espresso male: io parlavo di programmi aggiuntivi, non aggiornare librerie.

maxpaguro
Linux 0.x
Linux 0.x
Messaggi: 10
Iscritto il: mer 16 giu 2010, 15:04
Nome Cognome: massimo bernardini
Slackware: Sw32-13.1
Kernel: 2.6.33.4-smp

Re: Domande ai Packager (e slackbuild di prova)

Messaggio da maxpaguro »

Save a tutti voi! Sono nuovo qui - ma non di ieri! - e non vorrei sbagliare nè il posto nè il momento in cui presentarmi - se così fosse, scusatemi - ; sono anch'io interessato all'argomento in questione della pacchettizzazione e avrei l'ambizione, forse temeraria, di aiutare un pò in questo interessante "lavoraccio" del packager; temo però che "non sian da ciò le proprie penne"; comunque vi chiederei se cortesemente mi indicaste una guida per novizi per creare l'ambiente root dove testare i pacchetti; grazie ciao :)

Avatar utente
Thraphyx
Linux 2.x
Linux 2.x
Messaggi: 212
Iscritto il: ven 28 ago 2009, 22:43
Slackware: 14.1 multilib
Kernel: 3.10.17
Desktop: KDE 4.11.5

Re: Domande ai Packager (e slackbuild di prova)

Messaggio da Thraphyx »

Ansa89 ha scritto:
Thraphyx ha scritto:Si, sapevo dovesse essere vanilla, come ha anche gia detto Ansa89. Ma ovviamente se un pacchetto richiede dipendenze non-ufficiali, le si compila no?
E se un pacchetto richiedesse ad esempio una libreria più recente di quella ufficiale presente nella slackware, si ricompila, si installa e si crea il pacchetto? E dopo la si deve rimuovere per non inficiare su altre compilazioni?
Ovviamente devi avere installate tutte le dipendenze richieste dal programma che stai compilando.
In seguito va rimosso tutto per riavere la slack pulita.
Come sospettavo :D
Thraphyx ha scritto:
Il consiglio maggiore è il chroot.
Personalmente uso una current-64bit come uso abituale, una 13.1-64bit per compilare i pacchetti a 64bit e una 13.1-32bit chrootata per i pacchetti a 32bit.
Ovviamente va installato requiredbuilder.
Ok, come immaginavo, ma che differenze ci sono rispetto a una macchina virtuale? Posso presumere che si consumino meno risorse durante la compilazione, giusto?
Come hai giustamente detto: la macchina virtuale richiede molte più risorse (ram/cpu) rispetto a chroot.
Vada di chroot allora.
Thraphyx ha scritto:Scusate, un'altra domanda..
Usando gli SB di slackbuilds.org, prendevo i file, cambiavo qualcosa e lanciavo lo script. Ora creandone uno da me, ho prima installato il software con i classici ./configure&&make&&make install in /usr/local, per sapere eventualmente che opzioni passare al ./configure, e soprattutto per vedere quali file venivano creati e agire di conseguenza (tipo con la documentazione)..
È un approccio corretto? Voi come vi comportate?
Per vedere che opzioni passare a "./configure" (e in generale come strutturare uno slackbuild) prendi uno slackbuild da slacky.eu.
In generale ti posso dire che non ho mai visto usare "/usr/local" come prefix (di solito si usa "--prefix=/usr")
No, io mi riferivo al fatto che la compilazione classica ./configure&&make&&make install, senza parametri aggiuntivi, installa di default in /usr/local. Le opzioni del ./configure di cui parlavo non sono quelle standard (come ad esempio il path in /usr, etc..), ma quelle che variano da programma a programma e che magari bisogna impostare in modo particolare.
Ora che ci penso basterebbe anche solo scompattare i sorgenti e lanciare solo il ./configure per scoprire quali parametri è possibile passargli.. Volevo sapere voi come vi comportate sotto questo punto di vista quando create pacchetti di software nuovo :D
conraid ha scritto:veramente la linea è sempre stata quella di lasciare le librerie di default, se il programma richiede una libreria aggiornata significa che non è per la stable.
A meno di casi particolari quindi si lascia l'ultima versione compilabile sulla stable
Ah.. ok.. E potresti dirmi quali potrebbero essere questi casi particolari per cui si può anche aggiornare una libreria di sistema?

Comunque adesso il quadro della situazione inizia a farsi molto più definito :thumbright:

Avatar utente
conraid
Staff
Staff
Messaggi: 13630
Iscritto il: gio 14 lug 2005, 0:00
Nome Cognome: Corrado Franco
Slackware: current64
Desktop: kde
Località: Livorno
Contatta:

Re: Domande ai Packager (e slackbuild di prova)

Messaggio da conraid »

Thraphyx ha scritto:
conraid ha scritto:veramente la linea è sempre stata quella di lasciare le librerie di default, se il programma richiede una libreria aggiornata significa che non è per la stable.
A meno di casi particolari quindi si lascia l'ultima versione compilabile sulla stable
Ah.. ok.. E potresti dirmi quali potrebbero essere questi casi particolari per cui si può anche aggiornare una libreria di sistema?
una libreria di secondo piano che non fa andare un aggiornamento "importante" e che non comporti a suo volta il non funzionamento dei programmi standard. Se firefox 3.7 vorrà libpincopallino in versione aggiornata, probabilmente è utile aggiornare libpincopallino, ma se questo comporta il non funzionamento dei programmi linkati a libpincopallino in slackware allora non vale la pena.

A volte invece le librerie in Slackware sono "menomate", per esempio curys-sasl non ha il supporto sql, quindi dovecot e postfix non possono essere compilati per funzionare con sasl in abbinamento a mysql, allora solitamente ricompiliamo anche cyrus-sasl, ma solamente della stessa versione che è in Slackware, così che aggiunga solo dei plugin ma non stravolga il resto.
E come ti hanno detto la compili, la installi, compili gli altri programmi e la togli.
Per questo per fare il "compilatore" per slacky conviene avere una installazione "pulita e full" solo per questo compito

Diverso se ti fai i pacchetti per conto tuo.

di default parti dal presupposto che dei programmi originali non va toccato niente, i casi particolari vengono discussi nell'apposito forum

naturalmente parlo per creare pacchetti su slacky.eu, se vuoi farli per conto tuo è un altro discorso.
Per esempio io per slackers.it non seguo queste "direttive", compilo su -current e con alcune librerie compilate da me

Per il discorso del configure è logico che prima devi conoscere un minimo il programma e che parametri richiede, la maggior parte sono standard, ma non sempre è così.
Alcuni programmi non rispettano nemmeno i parametri e installano documentazione per esempio senza tenere conto di --mandir e --docdir, quindi bisogna o andare di sed nel makefile o spostarli dopo l'installazione

Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5441
Iscritto il: ven 2 giu 2006, 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

Re: Domande ai Packager (e slackbuild di prova)

Messaggio da ZeroUno »

maxpaguro ha scritto: comunque vi chiederei se cortesemente mi indicaste una guida per novizi per creare l'ambiente root dove testare i pacchetti; grazie ciao :)
Per la base:

Codice: Seleziona tutto

# mkdir /slack32
# mount /dev/hda /mnt/cdrom
# installpkg --root /slack32 /mnt/cdrom/slackware/{a,ap,d,e,f,k,kde,l,n,t,tcl,x,xap,y}/*.t?z
# umount /mnt/cdrom
e poi, per usarla

Codice: Seleziona tutto

# chroot /slack32
# . /etc/profile
questa è la base, poi io faccio anche

Codice: Seleziona tutto

# mount -t proc proc /proc
questo invece serve per ricordarmi che sono in chroot:

Codice: Seleziona tutto

# PS1="chroot32: \w > "
e altro.
naturalmente metto tutto dentro uno script
altri fanno sicuramente altre accortezze.

Poi se vuoi puoi anche fare il boot da questa macchina virtuale (per esempio se vuoi testare qualche pacchetto a S.O. up):
http://slacky.eu/forum/viewtopic.php?f=1&t=28951
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

maxpaguro
Linux 0.x
Linux 0.x
Messaggi: 10
Iscritto il: mer 16 giu 2010, 15:04
Nome Cognome: massimo bernardini
Slackware: Sw32-13.1
Kernel: 2.6.33.4-smp

Re: Domande ai Packager (e slackbuild di prova)

Messaggio da maxpaguro »

ZeroUno ha scritto:
maxpaguro ha scritto: comunque vi chiederei se cortesemente mi indicaste una guida per novizi per creare l'ambiente root dove testare i pacchetti; grazie ciao :)
Per la base:

Codice: Seleziona tutto

# mkdir /slack32
# mount /dev/hda /mnt/cdrom
# installpkg --root /slack32 /mnt/cdrom/slackware/{a,ap,d,e,f,k,kde,l,n,t,tcl,x,xap,y}/*.t?z
# umount /mnt/cdrom
e poi, per usarla

Codice: Seleziona tutto

# chroot /slack32
# . /etc/profile
questa è la base, poi io faccio anche

Codice: Seleziona tutto

# mount -t proc proc /proc
questo invece serve per ricordarmi che sono in chroot:

Codice: Seleziona tutto

# PS1="chroot32: \w > "
e altro.
naturalmente metto tutto dentro uno script
altri fanno sicuramente altre accortezze.

Poi se vuoi puoi anche fare il boot da questa macchina virtuale (per esempio se vuoi testare qualche pacchetto a S.O. up):
http://slacky.eu/forum/viewtopic.php?f=1&t=28951

Grazie ZeroUno,
intuisco più che capire i passaggi che mi hai mostrato;prima montare il DVD di Slack su una directory della / (cioè slack32) poi scaricarvi i pacchetti delle varie serie...; poi però mi perdo e ti sarei grato se mi spiegassi i singoli passaggi ( credo di esserci quasi ma ho bisogno di essere condotto quasi per mano per capire[-o< grazie ancora

Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5441
Iscritto il: ven 2 giu 2006, 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

Re: Domande ai Packager (e slackbuild di prova)

Messaggio da ZeroUno »

1- montare il dvd su /mnt/cdrom
2- creare la directory dove installare la slackware chrootata (ex. /slack32)
3- installare i pacchetti prendendoli direttamente dal dvd. installare tutti i pacchetti tranne kdei
4- smontare il cdrom.
installazione terminata.

per usarla devi dare il comando 'chroot /slack32', però ti carica una shell non profilata perchè non è un login. Di conseguenza fai una simulazione di login con '. /etc/profile' (occhio al punto spazio prima di /etc...)
tuttavia non è un sistema running quindi ti mancano un po' di cose. Per esempio, se dai un 'ps' ti risponde pikke, e allora dai il mount della proc.
Il PS1=.... serve per darti un prompt che ti consenta di distinguere al volo se stai lavorando nella macchina chrootata
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

maxpaguro
Linux 0.x
Linux 0.x
Messaggi: 10
Iscritto il: mer 16 giu 2010, 15:04
Nome Cognome: massimo bernardini
Slackware: Sw32-13.1
Kernel: 2.6.33.4-smp

Re: Domande ai Packager (e slackbuild di prova)

Messaggio da maxpaguro »

ZeroUno ti ringrazio per la gentilezza e competenza (mi hai chiarito le idee), avrò ancora bisogno di voi :thumbright: ciao

Avatar utente
Thraphyx
Linux 2.x
Linux 2.x
Messaggi: 212
Iscritto il: ven 28 ago 2009, 22:43
Slackware: 14.1 multilib
Kernel: 3.10.17
Desktop: KDE 4.11.5

Re: Domande ai Packager (e slackbuild di prova)

Messaggio da Thraphyx »

conraid ha scritto:
Thraphyx ha scritto:
conraid ha scritto:veramente la linea è sempre stata quella di lasciare le librerie di default, se il programma richiede una libreria aggiornata significa che non è per la stable.
A meno di casi particolari quindi si lascia l'ultima versione compilabile sulla stable
Ah.. ok.. E potresti dirmi quali potrebbero essere questi casi particolari per cui si può anche aggiornare una libreria di sistema?
una libreria di secondo piano che non fa andare un aggiornamento "importante" e che non comporti a suo volta il non funzionamento dei programmi standard. Se firefox 3.7 vorrà libpincopallino in versione aggiornata, probabilmente è utile aggiornare libpincopallino, ma se questo comporta il non funzionamento dei programmi linkati a libpincopallino in slackware allora non vale la pena.
Chiarissimo. Però mi viene in mente una cosa. Se un programma necessita della libpincopallino a una versione maggiore di quella in slackware per compilarsi, non si potrebbe compilarla all' interno del programma staticamente? Tipo aggiornare la lib, compilare il programma e downgradarla di nuovo.
Cioè così non si rischierebbe di non poter avere un programma nel repo ufficiale.
Lo so, sto divagando, però visto che ci sono voglio togliermi tutti i dubbi. :D
Per il discorso del configure è logico che prima devi conoscere un minimo il programma e che parametri richiede, la maggior parte sono standard, ma non sempre è così.
Alcuni programmi non rispettano nemmeno i parametri e installano documentazione per esempio senza tenere conto di --mandir e --docdir, quindi bisogna o andare di sed nel makefile o spostarli dopo l'installazione
Era proprio quello che intendevo.

A volte invece le librerie in Slackware sono "menomate", per esempio curys-sasl non ha il supporto sql, quindi dovecot e postfix non possono essere compilati per funzionare con sasl in abbinamento a mysql, allora solitamente ricompiliamo anche cyrus-sasl, ma solamente della stessa versione che è in Slackware, così che aggiunga solo dei plugin ma non stravolga il resto.
Capito.

Comunque grazie mille a tutti, veramente. Penso di essere pronto. Devo solo installare la Slack64 e iniziare a fare qualche pacchetto, poi chiedo a Loris! :thumbright:

PS.
Vorrei lasciare questo thread aperto in modo che, se volessi chiedere altro o se qualcun altro lo volesse, non ci sarà bisogno di aprire un'altra discussione, no?

Rispondi