Pagina 2 di 2
Re: removepkg e link simbolici orfani
Inviato: mar 1 nov 2016, 22:38
da erio
premesso che uno slackbuild dei driver e' una cosa molto gradita,ho anche io una brother non laser ho usato rpm2tgz per creare il pacchetto che installa in /opt, i driver sono a 32 bit,io ho un sistema a 64 bit servono delle glib-solib multilib, cups-compact32,cups-filter-compact32,
Re: removepkg e link simbolici orfani
Inviato: mar 1 nov 2016, 22:49
da joe
Si io avevo usato rpm2cpio, ma alla fine la sostanza non cambia.
Avevo messo un topic ad hoc per discutere l'installazione della stampante.
http://slacky.eu/forum/viewtopic.php?f=6&t=38867
Già col pacchetto che ho preparato adesso funziona tutto, anche a me sono serviti tre pacchetti multilib presi da alienbob (vedi altra discussione per i dettagli).
Quà però si voleva discutere un più in generale la gestione di un caso tipo questo secondo lo stile slackware.
Grazie comunque per il contributo

Re: removepkg e link simbolici orfani
Inviato: mar 1 nov 2016, 22:52
da erio
comunque lo script per creare il link a cups lo devi eseguire, credo.
Re: removepkg e link simbolici orfani
Inviato: mar 1 nov 2016, 23:05
da targzeta
E allora devi fare due pacchetti, uno per 32 e l'altro per 64 bit. una directory lib64 sotto un sistema a 32 bit non è bellissima!
Emanuele
Re: removepkg e link simbolici orfani
Inviato: mer 2 nov 2016, 12:57
da joe
erio ha scritto:comunque lo script per creare il link a cups lo devi eseguire, credo.
Sì, in pratica, siccome eseguire uno script di terze parti da dentro uno Slackbuild non è una scelta aderente ad esempio alle linee guida di SBo, ho osservato le operazioni che quello script esegue e le ho trasferite direttamente nello slackbuild.
Ad esempio lo script conteneva degli here document che venivano scritti su due files necessari a CUPS: il PPD e il file LPD wrapper. Per evitare l'esecuzione dello script, lo slackbuild estrae quegli here document (ho usato "sed" per lo scopo) e scrive direttamente lui i due files richiesti.
Analogamente ho riprodotto le altre operazioni dello script nello slackbuild, poca roba, qualche cambio di permessi su alcuni files e appunto la creazione di quel link simbolico di cui si parlava, operazione quest'ultima da fare solo se esiste la directory
"/usr/lib64/cups/filter".
Peccato che questa operazione condizionale non si possa eseguire in fase di installazione. Per i motivi che abbiamo detto nei post precedenti...
Tuttavia eseguirla in fase di build del pacchetto, porta sì alla necessità di creare due pacchetti diversi per diverse architetture, ma risolve il problema della presenza di CUPS prima dell'installazione.
Infatti se siamo su sistema a 64bit e installiamo il pacchetto creato specificatamente per sistemi a 64bit, anche se cups non fosse presente, il nostro link simbolico verrebbe creato regolarmente insieme alla sua directory madre e relativo percorso. In questo modo per far funzionare il driver basterebbe poi installare CUPS.
Re: removepkg e link simbolici orfani
Inviato: mer 2 nov 2016, 13:01
da joe
targzeta ha scritto:E allora devi fare due pacchetti, uno per 32 e l'altro per 64 bit. una directory lib64 sotto un sistema a 32 bit non è bellissima!
Emanuele
Già... direi allora che questa conclusione è la più corretta.
Se a qualcuno venisse qualche altra idea benvenga.
PS.
Per ogni altro dettaglio relativo al pacchetto dei driver brother hl2030/2035 vi inviterei a scrivere nell'altro topic dedicato. Come ho detto qua si voleva discutere un problema più generico.
Re: removepkg e link simbolici orfani
Inviato: mer 2 nov 2016, 18:33
da targzeta
Sì, ma i due pacchetti devono avere path diversi.
Per sistemi a 32bit:
per sistemi a 64bit:
Emanuele
Re: removepkg e link simbolici orfani
Inviato: mer 2 nov 2016, 20:53
da joe
Sì, in realtà ho mantenuto lo schema dello script di brother, cioè viene creato il path lib64 solo se il build viene fatto su sistemi a 64 bit (si può forzare anche da sistemi a 32bit impostando la var ARCH: ARCH=x86_64 ./bother-hl2030.SlackBuild ad esempio)
Codice: Seleziona tutto
# Automatically determine the architecture we're building on:
if [ -z "$ARCH" ]; then
case "$( uname -m )" in
i?86) ARCH=i386 ;;
arm*) ARCH=arm ;;
# Unless $ARCH is already set, use uname -m for all other archs:
*) ARCH=$( uname -m ) ;;
esac
fi
[...]
# Create LPD-wrapper link for 64bit systems only
if [ "$ARCH" = "x86_64" ]; then
mkdir -p $PKG/usr/lib64/cups/filter
ln -sf /usr/lib/cups/filter/brlpdwrapperHL2030 $PKG/usr/lib64/cups/filter/brlpdwrapperHL2030
fi
In questo modo si può creare il pacchetto a 64bit col relativo link simbolico, oppure a 32bit senza quel path. Ti torna?
Comunque poi caricherò tutto il malloppo così se vuoi potrai visionare lo SlackBuild in completo, è molto semplice, niente di chè...
Una cosa che c'entra poco: questi drivers che di fatto contengono binari a 32bit potrebbero essere utilizzati anche su architettura ARM ? Intendo allo stesso modo di come li sto usando su un sistema a 64bit... Cioè esistono multilib per ARM analoghe a quelle per sistemi a 32bit?