removepkg e link simbolici orfani

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
joe
Iper Master
Iper Master
Messaggi: 2713
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

removepkg e link simbolici orfani

Messaggioda joe » sab ott 29, 2016 12:17

Sto creando uno SlackBuild per i drivers proprietari della stampante Brother HL-2030 / 2035. Avevo già aperto un topic ad hoc:
viewtopic.php?f=6&t=38867&p=347940#p347940

L'installazione prevede l'esecuzione di uno script bash che tra le altre cose copia un file nel caso in cui il sistema sia a 64bit. Vi riporto la banale operazione:

Codice: Seleziona tutto

brotherlpdwrapper=/usr/lib/cups/filter/brlpdwrapperHL2030
brotherlpdwrapper64=/usr/lib64/cups/filter/brlpdwrapperHL2030
chmod a+x $brotherlpdwrapper
if [ -e /usr/lib64/cups/filter ]; then
   cp $brotherlpdwrapper  $brotherlpdwrapper64
fi

In pratica il ragionamento che fà è il seguente: se esiste la dir "/usr/lib/64/cups/filter", allora copia il file che sta in /usr/lib/ecc nella dir analoga /usr/lib64/ecc/ecc.
Se il sistema è a 32 bit, la dir /usr/lib64/cups/filter non esisterà e quella copia non avverrà. Fine.

Un'opzione è quella di piazzare quelle operazioni nello SlackBuild, leggermente modificate in modo che la copia avvenga all'interno della directory di costruzione del pacchetto:

Codice: Seleziona tutto

TMP=/tmp/brother-hl2030
cd $TMP
[...]
brotherlpdwrapper=usr/lib/cups/filter/brlpdwrapperHL2030
brotherlpdwrapper64=usr/lib64/cups/filter/brlpdwrapperHL2030
chmod a+x $brotherlpdwrapper
if [ -e /usr/lib64/cups/filter ]; then
   cp $brotherlpdwrapper  $brotherlpdwrapper64
fi

Cioè se sul sistema in cui si sta creando il pacchetto c'è la directory /usr/lib64/ecc/ecc, allora nel pacchetto crei quel file $brotherlpdwrapper64.
In questo modo se lancio lo SlackBuild da un sistema a 64 bit ecco che il pacchetto creato sarà corretto se installato in un sistema a 64bit, perchè quella directory lib64 esiste e "installpkg" andrà a copiarvi dentro. Ma quello stesso pacchetto sarebbe problematico qualora si tentasse di installarlo su un sistema a 32bit, perchè installpkg tenterebbe di copiare il contenuto della dir lib64 sul sistema, il che non sarebbe corretto.

Su LQ mi consigliavano allora di sostituire alla copia, la creazione di un link simbolico da eseguire, non in fase di build, ma in fase di installazione del pacchetto attraverso il doinst.sh:

Codice: Seleziona tutto

# Create LPD-wrapper link for 64bit systems
#
brotherlpdwrapper64=usr/lib64/cups/filter/brlpdwrapperHL2030
if [ "$(uname -m)" = "x86_64" ]; then
  [ ! -d /usr/lib64/cups/filter ] && mkdir /usr/lib64/cups/filter
  ( cd /usr/lib64/cups/filter
    ln -sf /usr/lib/cups/filter/brlpdwrapperHL2030 brlpdwrapperHL2030
  )
fi

In questo modo posso aver creato il pacchetto sia su un sistema a 64bit che su uno a 32... in ogni caso sarà possibile installarlo senza problemi su qualsiasi sistema sia esso a 32 o a 64 bit.

Problema:
Cosa succede quando disinstallo il pacchetto da un sistema a 64bit?
Provando a me resta il link simbolico orfano:

Codice: Seleziona tutto

# ls -l /usr/lib64/cups/filter/brlpdwrapperHL2030
lrwxrwxrwx 1 root root 39 ott 29 11:58 /usr/lib64/cups/filter/brlpdwrapperHL2030 -> /usr/lib/cups/filter/brlpdwrapperHL2030


La questione che avevo in mente di porvi vorrebbe essere più generale, anche se riferirci all'esempio del pacchetto che sto creando può aiutare a capire meglio:
Il doinst.sh può creare collegamenti simbolici, files, directories ecc ecc. Però questa roba che scrive sul sistema sembra non venga "registrata", nel senso che quando poi si va a rimuovere il pacchetto viene cancellato solo ciò che ha scritto installpkg senza considerare gli ulteriori files, dirs, links creati dal doinst.sh.
Come fare allora per creare un pacchetto che alla disinstallazione lasci il sistema pulito senza dimenticarsi files in giro?
Come applicare la cosa al caso proposto in esempio?

Spero la sezione sia azzeccata, anche se non mi riferisco a pacchetti del repo di Slacky.
Grazie in anticipo! :)

Avatar utente
targzeta
Iper Master
Iper Master
Messaggi: 6469
Iscritto il: gio nov 03, 2005 14:05
Nome Cognome: Emanuele Tomasi
Slackware: current
Kernel: latest stable
Desktop: IceWM
Località: Carpignano Sal. (LE) <-> Pisa

Re: removepkg e link simbolici orfani

Messaggioda targzeta » dom ott 30, 2016 20:05

Ora non ho verificato, però se il link simbolico è creato all'interno della directory del pacchetto, alla creazione il doinst.sh si crea da solo con i comandi corretti a creare il link, e mi sa che il link stesso viene rimosso all'eliminazione del pacchetto.

Tu quel doinst.sh l'hai creato a mano ho viene creato da makepkg?

Emanuele
Linux Registered User #454438
Se pensi di essere troppo piccolo per fare la differenza, prova a dormire con una zanzara -- Dalai Lama
20/04/2013 - Io volevo Rodotà 

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2713
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: removepkg e link simbolici orfani

Messaggioda joe » dom ott 30, 2016 21:46

Ciao e grazie per la risposta,

Confermo quanto hai detto perchè ho testato poco fà la cosa. Creando il link da dentro lo slackbuild questo viene prima cancellato quando si crea il pacchetto e quei comandi vengono "trascritti" in coda al doinst grazie all'opzione "-l y" di makepkge. Per trascriverli in testa al doinst.sh c'è l'opzione -p "prepend" di makepkge.

Il doinst.sh l'avevo creato a mano perchè deve fare anche altre cose, riavviare CUPS ad esempio ecc.

Il problema saltava fuori dalla questione: creo un solo pacchetto sia per slackware 32bit che per slackware64. Perchè banalmente nel secondo caso si deve creare il link simbolico: /usr/lib64/cups/filter/brlpdwrapperHL2030

Ho cercato di sintetizzare la questione qui in questo messaggio:
https://www.linuxquestions.org/question ... ost5624464

Lì hanno concluso che sarebbe meglio cercare di adattare il pacchetto al sistema quindi un pacchetto per 32bit e un'altro per 64bit.
Ovviamente se si crea il pacchetto con lo slackbuild non ci sono problemi, $ARCH viene rilevata o può essere forzata in modo da ottenere un pacchetto per l'architettura desiderata.
Il punto era se si volesse distribuire il pacchetto già fatto... non so se mi sono spiegato.

Avatar utente
targzeta
Iper Master
Iper Master
Messaggi: 6469
Iscritto il: gio nov 03, 2005 14:05
Nome Cognome: Emanuele Tomasi
Slackware: current
Kernel: latest stable
Desktop: IceWM
Località: Carpignano Sal. (LE) <-> Pisa

Re: removepkg e link simbolici orfani

Messaggioda targzeta » lun ott 31, 2016 11:22

Ti sei spiegato benissimo: vuoi controllare a run time se il sistema che sta installando il pacchetto è a 32 o a 64 bit e, nel caso, creare il link simbolico.

È un buon approccio. Credo che basti creare il link simbolico nel doinst.sh come lo fa makepkg affinché removepkg lo cancelli.

Emanuele
Linux Registered User #454438
Se pensi di essere troppo piccolo per fare la differenza, prova a dormire con una zanzara -- Dalai Lama
20/04/2013 - Io volevo Rodotà 

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2713
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: removepkg e link simbolici orfani

Messaggioda joe » lun ott 31, 2016 14:20

Il problema è proprio quello: cioè, non è vero che basta creare il link nel doinst.sh come lo fa makepkg, semplicemente perchè makepkg non aggiunge un controllo dell'architettura al doinst.sh.
E quando provo ad aggiungere il controllo dell'architettura ecco che removepkg non elimina più il link creato.

Ho provato a fare una cosa più semplice tanto per testare come funziona installpkg e come pilota l'esecuzione del doinst.sh.
Ho creato uno slackbuild che crea il pacchetto "test64" il quale contiene banalmente un albero di directories in cui dentro vi è un file di testo di prova:

Codice: Seleziona tutto

/test/foo/bar

Inoltre se il pacchetto viene "installato" (non "creato") su sistema a 64 bit si vuole creare anche il link simbolico.

Codice: Seleziona tutto

/test/foo64/bar

Ciò che si vuole ottenere è:
  • Discriminare in fase d'installazione ciò che il pacchetto va ad installare (solo su sistema a 64bit si vuole creare il link simbolico e il relativo percorso, mentre se l'installazione avviene su sistema 32bit la dir /test/foo64 non deve essere installata).
  • Fare in modo che removepkg non lasci alcun file sul sistema, inlcuso il link simbolico.
Vi allego due versioni dello slackbuild (slack-desc e doinst.sh sono hardcoded nello script).

    test64.SlackBuild
    Usa un doinst.sh con controllo dell'architettura, scritto a mano. Crea il pacchetto con "makepkg -l n", cioè non consente a makepkg di eliminare il link simbolico creato e aggiungere i comandi per ricrearlo nel doinst.sh (perchè quei comandi li ho già inseriti a mano, più il controllo architettura)
    Produce un pacchetto che però alla rimozione non elimina il link simbolico.

    test64v2.SlackBuild
    Usa un doinst.sh praticamente vuoto e lascia che makepkg lo riempia coi comandi per cancellare e ricreare il link simbolico.
    Crea in ogni caso il link simbolico (a prescindere dall'architettura) e serve per a capire cosa fà installpkg di diverso rispetto al primo pacchetto.

Si può testare il tutto provando a generare i due diversi pacchetti che verranno creati in /tmp (tra i due cambia il tag "build" nel nome del pacchetto). Poi si può provare ad installare il primo e fare caso a ciò che fà installpkg quando esegue il doinst.sh. Quindi rimuovere il pacchetto con removepkg e fare caso che vi è ancora il link simbolico orfano /test/foo64/bar, quindi rimuovere a mano la dir "/test".
A questo punto provare ad installare il secondo pacchetto (build = 2) e osservare che installpkg esegue qualche operazione in più. Se poi si rimuove il pacchetto sta volta vengono regolarmente rimossi tutti i files installati.

Aggiungo ciò che mostra l'installazione: ho aggiunto un "set -x" nel doinst.sh in modo che venga mostrato a video cosa fa installpkg.
Ecco il primo pacchetto:

Codice: Seleziona tutto

Executing install script for test64-0.1-noarch-1hb.txz.
+ pushd test/foo64
+ rm -rf bar
+ popd
+ '[' -z ']'
++ uname -m
+ ARCH=x86_64
+ '[' x86_64 = x86_64 ']'
+ cd test/foo64
+ ln -sf /test/foo/bar bar


Ed ecco il secondo:

Codice: Seleziona tutto

Executing install script for test64-0.1-noarch-2hb.txz.
+ pushd test/foo64
+ rm -rf bar
+ popd
+ pushd test/foo64
+ ln -sf /test/foo/bar bar
+ popd

Come si vede nel secondo caso vengono eseguiti quei comandi "pushd" e "popd" in più che durante l'installazione del primo pacchetto mancano.
Allegati
test64v2.SlackBuild.TXT
(974 Byte) Scaricato 38 volte
test64.SlackBuild.TXT
(801 Byte) Scaricato 40 volte

Avatar utente
targzeta
Iper Master
Iper Master
Messaggi: 6469
Iscritto il: gio nov 03, 2005 14:05
Nome Cognome: Emanuele Tomasi
Slackware: current
Kernel: latest stable
Desktop: IceWM
Località: Carpignano Sal. (LE) <-> Pisa

Re: removepkg e link simbolici orfani

Messaggioda targzeta » lun ott 31, 2016 14:44

Scusa se non ho letto tutto, però tu devi vedere il removepkg cosa fa, non l'installpkg.

Codice: Seleziona tutto

extract_links() {
 sed -n 's,^[ ]*( [ ]*cd[ ]* \(.*\) [ ]*; [ ]*rm [ ]*-rf[ ]* \(.*\) [ ]*)[ ]*$,\1/\2,p'
}
...
extract_links < $ADM_DIR/scripts/$PKGNAME | sort -u > $TMP/del_link_list$$
come vedi lui fa una grep per prelevare il path completo da eliminare. Quindi mi viene da pensare che se nel tuo doinst.sh ci metti qualcosa nella stessa forma, ecco che il removepkg ti cancella il link! In particolare, nel tuo SlackBuild dovresti aggiungere (almeno) uno spazio tra il nome della directory e il ';', così:

Codice: Seleziona tutto

( cd test/foo64 ; rm -rf bar )

Emanuele
Linux Registered User #454438
Se pensi di essere troppo piccolo per fare la differenza, prova a dormire con una zanzara -- Dalai Lama
20/04/2013 - Io volevo Rodotà 

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2713
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: removepkg e link simbolici orfani

Messaggioda joe » lun ott 31, 2016 15:02

Non ben capito perchè, ma ho testato aggiungendo uno spazio prima del "punto e virgola" ed efettivamente si comporta diversamente, direi in modo corretto. Credevo il ";" fosse interpretato come nella shell, cioè separatore di comandi e stop, invece se c'è il grep di mezzo le cose evidentemente cambiano.

Per il momento grazie, appena riesco faccio qualche altra prova.

Avatar utente
targzeta
Iper Master
Iper Master
Messaggi: 6469
Iscritto il: gio nov 03, 2005 14:05
Nome Cognome: Emanuele Tomasi
Slackware: current
Kernel: latest stable
Desktop: IceWM
Località: Carpignano Sal. (LE) <-> Pisa

Re: removepkg e link simbolici orfani

Messaggioda targzeta » lun ott 31, 2016 15:31

No, non è che si comporta diversamente. Nel doinst.sh ha proprio la funzione di separare i due comandi, però il "sed" eseguito dal removepkg per estrarre dal doinst.sh i path dei link simbolici vuole (almeno) uno spazio tra la directory e il ';' e (almeno) uno spazio tra il ';' e il comando 'rm':

Codice: Seleziona tutto

 sed -n 's,^[ ]*( [ ]*cd[ ]* \(.*\) [ ]*; [ ]*rm [ ]*-rf[ ]* \(.*\) [ ]*)[ ]*$,\1/\2,p'
Prova ad eseguire il comando su un doinst.sh.

Qui un esempio su quello di pango (Slackware64-current):

Codice: Seleziona tutto

cat /var/log/scripts/pango-1.38.1-x86_64-1
( cd usr/lib64 ; rm -rf libpangoft2-1.0.so.0 )
( cd usr/lib64 ; ln -sf libpangoft2-1.0.so.0.3800.1 libpangoft2-1.0.so.0 )
( cd usr/lib64 ; rm -rf libpangocairo-1.0.so.0 )
( cd usr/lib64 ; ln -sf libpangocairo-1.0.so.0.3800.1 libpangocairo-1.0.so.0 )
( cd usr/lib64 ; rm -rf libpangoxft-1.0.so.0 )
( cd usr/lib64 ; ln -sf libpangoxft-1.0.so.0.3800.1 libpangoxft-1.0.so.0 )
( cd usr/lib64 ; rm -rf libpango-1.0.so )
( cd usr/lib64 ; ln -sf libpango-1.0.so.0.3800.1 libpango-1.0.so )
( cd usr/lib64 ; rm -rf libpango-1.0.so.0 )
( cd usr/lib64 ; ln -sf libpango-1.0.so.0.3800.1 libpango-1.0.so.0 )
( cd usr/lib64 ; rm -rf libpangocairo-1.0.so )
( cd usr/lib64 ; ln -sf libpangocairo-1.0.so.0.3800.1 libpangocairo-1.0.so )
( cd usr/lib64 ; rm -rf libpangoft2-1.0.so )
( cd usr/lib64 ; ln -sf libpangoft2-1.0.so.0.3800.1 libpangoft2-1.0.so )
( cd usr/lib64 ; rm -rf libpangoxft-1.0.so )
( cd usr/lib64 ; ln -sf libpangoxft-1.0.so.0.3800.1 libpangoxft-1.0.so )
( cd usr/doc/pango-1.38.1 ; rm -rf html )
( cd usr/doc/pango-1.38.1 ; ln -sf /usr/share/gtk-doc/html/pango html )

Codice: Seleziona tutto

sed -n 's,^[ ]*( [ ]*cd[ ]* \(.*\) [ ]*; [ ]*rm [ ]*-rf[ ]* \(.*\) [ ]*)[ ]*$,\1/\2,p' /var/log/scripts/pango-1.38.1-x86_64-1
usr/lib64/libpangoft2-1.0.so.0
usr/lib64/libpangocairo-1.0.so.0
usr/lib64/libpangoxft-1.0.so.0
usr/lib64/libpango-1.0.so
usr/lib64/libpango-1.0.so.0
usr/lib64/libpangocairo-1.0.so
usr/lib64/libpangoft2-1.0.so
usr/lib64/libpangoxft-1.0.so
usr/doc/pango-1.38.1/html

Non c'è niente di magico!
Emanuele
Linux Registered User #454438
Se pensi di essere troppo piccolo per fare la differenza, prova a dormire con una zanzara -- Dalai Lama
20/04/2013 - Io volevo Rodotà 

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2713
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: removepkg e link simbolici orfani

Messaggioda joe » lun ott 31, 2016 17:45

Niente di magico, hai ragione, avevo dimenticato che i pkgtools sono degli script bash facilmente ispezionabili.
Tuttavia non mi tornano i conti completamente, non temete, il post è lungo ma si legge in fretta. ;)

Di seguito vi posto due SlackBuilds.
In entrambi viene eseguita la creazione di un link simbolico:

Codice: Seleziona tutto

mkdir -p $PKG/test/foo $PKG/test/foo64
ln -sf /test/foo/bar $PKG/test/foo64/bar

Però nel secondo non c'è doinst.sh e viene lanciato makepkg con "-l y" cioè: rimuovi i symlinks e ricreali all'installazione editando un doinst.sh automaticamente.
Nel primo invece c'è un doinst.sh che come vedete sotto, se ARCH=x86_64 dovrebbbe fare le stesse cose dell'altro, inoltre in questo caso makepkg ha l'opzione "-l n" in modo che il doinst.sh non venga toccato.

Codice: Seleziona tutto

#!/bin/bash

NAME=test64
VERSION=0.1
ARCH=noarch
BUILD=1
TAG=hb
CWD=$(pwd)
TMP=/tmp/build
PKG=/tmp/package-$NAME

[ -d $PKG ] && rm -r $PKG
mkdir -p $PKG/test/foo $PKG/test/foo64
echo "this is just a test" > $PKG/test/foo/bar
ln -sf /test/foo/bar $PKG/test/foo64/bar
mkdir $PKG/install
cat <<SLACKDESC > $PKG/install/slack-desc
      |---------------------------------|
test64:
test64: Test 64
test64:
test64: Just to test doinst.sh behavior
test64:
test64:
test64:
test64:
test64:
test64:
test64:
SLACKDESC

cat <<'DOINST' > $PKG/install/doinst.sh
( cd test/foo64 ; rm -rf bar )
[ -z $ARCH ] && ARCH=$(uname -m)
if [ "$ARCH" = x86_64 ]; then
  ( cd test/foo64 ; ln -sf /test/foo/bar bar)
else
  rm -rf test/foo64
fi
DOINST

cd $PKG
makepkg -l n -c n /tmp/$NAME-$VERSION-$ARCH-${BUILD}${TAG}.txz


Codice: Seleziona tutto

#!/bin/bash

NAME=test64
VERSION=0.1
ARCH=noarch
BUILD=2
TAG=hb
CWD=$(pwd)
TMP=/tmp/build
PKG=/tmp/package-$NAME

[ -d $PKG ] && rm -r $PKG
mkdir -p $PKG/test/foo $PKG/test/foo64
echo "this is just a test" > $PKG/test/foo/bar
ln -sf /test/foo/bar $PKG/test/foo64/bar
mkdir $PKG/install
cat <<SLACKDESC > $PKG/install/slack-desc
      |---------------------------------|
test64:
test64: Test 64
test64:
test64: Just to test doinst.sh behavior
test64:
test64:
test64:
test64:
test64:
test64:
test64:
SLACKDESC

cd $PKG
makepkg -l y -c n /tmp/$NAME-$VERSION-$ARCH-${BUILD}${TAG}.txz


Se provo ad installare e rimuovere i due pacchetti (ovviamente uno alla volta) ottengo un output un po' diverso nei due casi perchè i files installati risultano differenti:
Primo pacchetto

Codice: Seleziona tutto

FILE LIST:
./
install/
install/doinst.sh
install/slack-desc
test/
test/foo/
test/foo/bar
test/foo64/
test/foo64/bar

Fate caso alla presenza del link simbolico "test/foo64/bar". makepkg non lo ha eliminato perchè c'era l'opzione "-l n".
Il link però viene rimosso e ricreato dal doinst.sh. Cosicchè quando si va a disinstallare, removepkg tenta di rimuoverlo due volte: fate caso al /test/foo64/bar no longer exists. Skipping. di seguito:

Codice: Seleziona tutto

# removepkg test64

Removing package /var/log/packages/test64-0.1-noarch-1hb...
Removing files:
  --> Deleting symlink /test/foo64/bar
  --> Deleting /test/foo/bar
  --> /test/foo64/bar no longer exists. Skipping.
  --> Deleting empty directory /test/foo64/
  --> Deleting empty directory /test/foo/
  --> Deleting empty directory /test/



Invece nel caso del secondo pacchetto ecco cosa ottengo:

Codice: Seleziona tutto

FILE LIST:
./
install/
install/doinst.sh
install/slack-desc
test/
test/foo/
test/foo/bar
test/foo64/

Questa volta il link simbolico è stato rimosso da makepkg e non risulta tra i files installati.
Alla disinstallazione ecco che tutto appare più preciso, cioè non ci sono tentativi di rimozione andati a vuoto.

Codice: Seleziona tutto

# removepkg test64

Removing package /var/log/packages/test64-0.1-noarch-2hb...
Removing files:
  --> Deleting symlink /test/foo64/bar
  --> Deleting /test/foo/bar
  --> Deleting empty directory /test/foo64/
  --> Deleting empty directory /test/foo/
  --> Deleting empty directory /test/


Domanda come dovrei gestire la faccenda nel modo più pulito?
Come potrei fare cioè a rimuovere il link con makepkg senza che venga automaticamente editato il doinst.sh (visto che già contiene i comandi per la gestione dell'unico link)??

Avatar utente
targzeta
Iper Master
Iper Master
Messaggi: 6469
Iscritto il: gio nov 03, 2005 14:05
Nome Cognome: Emanuele Tomasi
Slackware: current
Kernel: latest stable
Desktop: IceWM
Località: Carpignano Sal. (LE) <-> Pisa

Re: removepkg e link simbolici orfani

Messaggioda targzeta » lun ott 31, 2016 18:03

Devi lasciare '-l y' e non creare il link nella directory del pacchatto ma solo nel doinst.sh. Ovviamente se il file non esiste, il removepkg non lo rimuoverà, ma non importa, è nella logica di quello che vuoi fare te.

Emanuele
Linux Registered User #454438
Se pensi di essere troppo piccolo per fare la differenza, prova a dormire con una zanzara -- Dalai Lama
20/04/2013 - Io volevo Rodotà 

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2713
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: removepkg e link simbolici orfani

Messaggioda joe » lun ott 31, 2016 19:26

Ok, rispetto a prima ho modificato le seguenti due righe nello slackbuild con BUILD=1:

Codice: Seleziona tutto

#ln -sf /test/foo/bar $PKG/test/foo64/bar

Codice: Seleziona tutto

makepkg -l y -c n /tmp/$NAME-$VERSION-$ARCH-${BUILD}${TAG}.txz

Sembra funzionare come ci si aspetta, quando la ARCH è "x86_64".
Se invece si proba ad installare così:

Codice: Seleziona tutto

#ARCH=i386 installpkg /tmp/test64-0.1-noarch-1hb.txz

Ecco cosa dice quando si rimuove:

Codice: Seleziona tutto

# removepkg test64

Removing package /var/log/packages/test64-0.1-noarch-1hb...
Removing files:
  --> /test/foo64/bar (symlink) no longer exists. Skipping.
  --> Deleting /test/foo/bar
  --> /test/foo64/ no longer exists. Skipping.
  --> Deleting empty directory /test/foo/
  --> Deleting empty directory /test/

È abbastanza ovvio: nel doinst.sh la directory "foo64" viene rimossa in questo caso.
Nonostante ciò resta registrata in /var/log/packages/test64-0.1-1hb.
Quindi removepkg tenta di eliminarla, ma si accorge che non c'è più e lascia perdere riportando "Skipping".
Idem per il link simbolico, removepkg parsa il doinst.sh e rileva la creazione di quel link, ma in realtà quella roba sta in un'operazione condizionale che nel caso presente non viene eseguita. Allora tenta di cancellarlo, ma non trovandolo lascia perdere anche sta volta.
Tutto sommato la rimozione lascia il sistema pulito anche nel caso in cui ARCH sia impostata diversamente:

Codice: Seleziona tutto

# ls /tree
/bin/ls: impossibile accedere a '/tree': File o directory non esistente

La domanda anche sta volta però me la pongo, è una soluzione pulita anche "formalmente"?
Nel caso ARCH diverso da x86_64 bisogna prevedere qualche altra operazione affinchè il pacchetto funzioni come "da manuale". O può già andare bene così?

Avatar utente
targzeta
Iper Master
Iper Master
Messaggi: 6469
Iscritto il: gio nov 03, 2005 14:05
Nome Cognome: Emanuele Tomasi
Slackware: current
Kernel: latest stable
Desktop: IceWM
Località: Carpignano Sal. (LE) <-> Pisa

Re: removepkg e link simbolici orfani

Messaggioda targzeta » lun ott 31, 2016 20:06

Alla tua domanda non so rispondere perché non so come funziona il software che vuoi pacchettizzare. Però mi chiedo perché creare una directory vuota, foo64. Il doinst non crea solo il link? Perché mettere una directory nel pacchetto?

Emanuele
Linux Registered User #454438
Se pensi di essere troppo piccolo per fare la differenza, prova a dormire con una zanzara -- Dalai Lama
20/04/2013 - Io volevo Rodotà 

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2713
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: removepkg e link simbolici orfani

Messaggioda joe » mar nov 01, 2016 14:54

Anzitutto grazie per le risposte e la disponibilità! :)

L'ho spiegato nel primo messaggio del topic, primissime righe:
- sto pacchettizzando i drivers della stampante Brother HL2030 e HL2035
- si parte dagli RPM e si spacchettano, poi si deve eseguire uno script, tale "cupswrapper" che crea due files PPD e LPD wrapper e fa una copia del file /usr/lib/cups/filter/brlpdwrapperHL2030 in /usr/lib64/eccecc... Ma la fa solo se esiste quella directory, cioè solo se il sistema è a 64bit:

Codice: Seleziona tutto

brotherlpdwrapper=/usr/lib/cups/filter/brlpdwrapperHL2030
brotherlpdwrapper64=/usr/lib64/cups/filter/brlpdwrapperHL2030
chmod a+x $brotherlpdwrapper
if [ -e /usr/lib64/cups/filter ]; then
   cp $brotherlpdwrapper  $brotherlpdwrapper64
fi


- io vorrei che il pacchetto che sto creando faccia le stesse cose e le faccia in fase di installazione, non in fase di build, così come abbiamo già detto con un unico pacchetto si possono installare i drivers sia su sistemi a 64 che a 32 bit. Allo stesso tempo voglio che quando lo disinstallo ripulisca tutto.

Per semplificare le cose mi sono inventato il pacchetto "test64" proprio perchè così non è necessario capire cosa fa. Infatti non fa null'altro che scrivere il file /test/foo/bar e qualora si stia installando su un un sistema a 64bit crea il collegamento /test/foo64/bar al primo file. In qualche modo però, se è il caso, anche la directory /test/foo64 dovrà essere creata per ospitare al suo interno il link. Ecco perchè la creavo nello slackbuild...
Pensi che si possa creare in altro modo, non so, tipo attraverso il doinst.sh?
Ma poi non verrà rimossa da removepkg... E questo volevo evitarlo. :roll:
Non dare per scontato nulla perchè, come avrai notato, non sono assolutamente esperto nè di slackbuild nè di doinst ecc...

Ho provato a modificare lo slackbuild e il doinst.sh, ho tolto la directory foo64 dallo slackbuild (vedi riga commentata) e l'ho creata col doinst.sh. Ma così la dir /test/foo64 non viene poi disinstallata.
Comunque ecco lo script:

Codice: Seleziona tutto

#!/bin/bash

NAME=test64
VERSION=0.1
ARCH=noarch
BUILD=1
TAG=hb
CWD=$(pwd)
TMP=/tmp/build
PKG=/tmp/package-$NAME

[ -d $PKG ] && rm -r $PKG
mkdir -p $PKG/test/foo
#mkdir -p $PKG/test/foo64
echo "this is just a test" > $PKG/test/foo/bar
#ln -sf /test/foo/bar $PKG/test/foo64/bar
mkdir $PKG/install
cat <<SLACKDESC > $PKG/install/slack-desc
      |---------------------------------|
test64:
test64: Test 64
test64:
test64: Just to test doinst.sh behavior
test64:
test64:
test64:
test64:
test64:
test64:
test64:
SLACKDESC

cat <<'DOINST' > $PKG/install/doinst.sh
[ -z $ARCH ] && ARCH=$(uname -m)
if [ "$ARCH" = x86_64 ]; then
  mkdir -p test/foo64
  ( cd test/foo64 ; rm -rf bar )
  ( cd test/foo64 ; ln -sf /test/foo/bar bar)
fi
DOINST

cd $PKG
makepkg -l y -c n /tmp/$NAME-$VERSION-$ARCH-${BUILD}${TAG}.txz

Avatar utente
targzeta
Iper Master
Iper Master
Messaggi: 6469
Iscritto il: gio nov 03, 2005 14:05
Nome Cognome: Emanuele Tomasi
Slackware: current
Kernel: latest stable
Desktop: IceWM
Località: Carpignano Sal. (LE) <-> Pisa

Re: removepkg e link simbolici orfani

Messaggioda targzeta » mar nov 01, 2016 17:53

È giusto. Però, seguendo le direttive dello script originale, non devi creare il link se l'architettura è a 64bit, ma devi creare il link solo se esiste la directory padre '/usr/lib64/cups/filter/'. Questo lo puoi fare dal doinst.sh ed è giusto che poi che la directory non venga cancellata (viene creata all'installazione del pacchetto cups...e altri).

Emanuele
Linux Registered User #454438
Se pensi di essere troppo piccolo per fare la differenza, prova a dormire con una zanzara -- Dalai Lama
20/04/2013 - Io volevo Rodotà 

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2713
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: removepkg e link simbolici orfani

Messaggioda joe » mar nov 01, 2016 20:34

Vero, ma cosa succederebbe se ad esempio sul sistema non fosse installato prima "cups o altri"?
Succederebbe che il collegamento non verrebbe creato.
Quando poi l'utente installerà cups perchè capisce che è richiesto, allora la directory verrà creata, ma alla fine non conterrà il link simbolico necessario al driver.

Quindi non so, basarsi pedissequamente su quello script di brother non è l'opzione più corretta. Anche perchè è un rpm fatto per sistemi tipo redhat fedora ecc... e la le dipendenze sono gestite in modo differente rispetto a Slackware...
Ti pare?
Sto sbagliando?
Come risolvere?