[PKGBUILD] Déplacement, suppression de fichiers (résolu)

[Tristelune]

Salut à tous,

j'ai créé il y a quelques temps le PKGBUILD pour les pilotes de mon imprimante:

https://aur.archlinux.org/packages/cn/c ... 0/PKGBUILD

Pour la version 6 j'ai supprimé des liens symboliques du PKGBUILD. Avant la fonction package() était:

Code : Tout sélectionner

package() {
    # get id of printer model   
    _cmd=$(find ${srcdir}/cnijfilter-source-${_pkgver} -type f -name cif${_model}.conf -path '*[\d]*' -printf '%P' \
        | gawk -F/ '{print $1}')
    _id=${_cmd}


    for dir in ppd cnijfilter lgmon cngpijmon cngpijmnt libs cngpij pstocanonij backend backendnet cngpijmon/cnijnpr maintenance; do
        cd "${srcdir}/cnijfilter-source-${_pkgver}/${dir}"
        make install DESTDIR="${pkgdir}"
    done

    # Install ${_id} libraries
    install -d ${pkgdir}/usr/lib/
    install -m 755 ${srcdir}/cnijfilter-source-${_pkgver}/${_id}/${_libdir}/*so.* ${pkgdir}/usr/lib/
    install -d ${pkgdir}/usr/lib/bjlib/
    install -m 644 ${srcdir}/cnijfilter-source-${_pkgver}/${_id}/database/* ${pkgdir}/usr/lib/bjlib/
    # Install common libraries
    install -m 755 ${srcdir}/cnijfilter-source-${_pkgver}/com/${_libdir}/*so.* ${pkgdir}/usr/lib/
    install -m 666 ${srcdir}/cnijfilter-source-${_pkgver}/com/ini/* ${pkgdir}/usr/lib/bjlib/
    # Make symbolic links for libraries
    cd ${pkgdir}/usr/lib/
    ln -s libcnnet.so.*.*.* libcnnet.so
    for _l in cmcm cnclapi cnclbjcmd cnclui ess; do
        ln -s libcnbp${_l}${_id}.so.*.*.* libcnbp${_l}${_id}.so
    done
    ln -s libcnbpess${_id}.so.*.*.* libcnbpo${_id}.so

    # Install license file
    cd ${srcdir}/cnijfilter-source-${_pkgver}
    install -d ${pkgdir}/usr/share/licenses/${pkgname}/
    install -m 644 LICENSE-* ${pkgdir}/usr/share/licenses/${pkgname}/
}

Et maintenant:

Code : Tout sélectionner

package() {
	# get id of printer model	
	_cmd=$(find ${srcdir}/cnijfilter-source-${_pkgver} -type f -name cif${_model}.conf -path '*[\d]*' -printf '%P' \
		| gawk -F/ '{print $1}')
	_id=${_cmd}
	

	for dir in ppd cnijfilter lgmon cngpijmon cngpijmnt libs cngpij pstocanonij backend backendnet cngpijmon/cnijnpr maintenance; do
		cd "${srcdir}/cnijfilter-source-${_pkgver}/${dir}"
		make install DESTDIR="${pkgdir}" 
	done

	# Install ${_id} libraries
	install -d ${pkgdir}/usr/lib/
	install -m 755 ${srcdir}/cnijfilter-source-${_pkgver}/${_id}/${_libdir}/*so.* ${pkgdir}/usr/lib/
	install -d ${pkgdir}/usr/lib/bjlib/
	install -m 644 ${srcdir}/cnijfilter-source-${_pkgver}/${_id}/database/* ${pkgdir}/usr/lib/bjlib/
	# Install common libraries
	install -m 755 ${srcdir}/cnijfilter-source-${_pkgver}/com/${_libdir}/*so.* ${pkgdir}/usr/lib/
	install -m 666 ${srcdir}/cnijfilter-source-${_pkgver}/com/ini/* ${pkgdir}/usr/lib/bjlib/

	# Install license file
	cd ${srcdir}/cnijfilter-source-${_pkgver}
	install -d ${pkgdir}/usr/share/licenses/${pkgname}/
	install -m 644 LICENSE-* ${pkgdir}/usr/share/licenses/${pkgname}/
}

Donc les liens symboliques ne sont plus créés. Mon problème: si je mets le paquet à jour, les liens symboliques restent et ne servent plus à rien. Ils n'appartiennent plus à aucun paquet. Si je réessaie d'installer la version avec les liens symboliques j'obtiens:

Code : Tout sélectionner

cnijfilter-mg6300: /usr/lib/libcnbpcmcm408.so exists in filesystem
cnijfilter-mg6300: /usr/lib/libcnbpcnclapi408.so exists in filesystem
cnijfilter-mg6300: /usr/lib/libcnbpcnclbjcmd408.so exists in filesystem
cnijfilter-mg6300: /usr/lib/libcnbpcnclui408.so exists in filesystem
cnijfilter-mg6300: /usr/lib/libcnbpess408.so exists in filesystem
cnijfilter-mg6300: /usr/lib/libcnbpo408.so exists in filesystem
cnijfilter-mg6300: /usr/lib/libcnnet.so exists in filesystem
Errors occurred, no packages were upgraded.

Donc ils n'ont pas été enlevés. Ma question: comment on remédie à ça ? J'ai également un autre paquet ou je dois déplacer un fichier dans l'arborescence et le problème se représentera. Je suppose qu'il faut utiliser un .install, mais ce n'est pas encore clair ce qu'il faut y mettre.

Merci!

[benjarobin]

les liens symboliques restent et ne servent plus à rien

Ceci ne devrait jamais arriver. Cela m'étonnerait qu'il y est un bug de ce genre dans pacman. Tu ne nous dit pas tout...

Quel est la sortie de

Code : Tout sélectionner

pacman -Qo /usr/lib/libcnbpcmcm408.so

[Tristelune]

J'y ai encore réfléchi et le meilleure moyen de résoudre ce problème est de désinstaller complètement le paquet avant de l'installer à nouveau. Mais je suppose que c'est censé être ce qui se passe, d'autres y ont pensé avant moi. Remarque qui peut avoir son importance: comme il s'agit d'un PKGBUILD je fais tout avec yaourt. Alors je simule ce qui s'est passé à l'époque. Tout d'abord mon ancien PKGBUILD ici. Je désinstalle tout, reconstruis mon paquet en local et l'installe avec

Code : Tout sélectionner

yaourt -U cnijfilter-mg6300-3.80-5-x86_64.pkg.tar.xz 

Après l'installation

Quel est la sortie de

Code : Tout sélectionner

pacman -Qo /usr/lib/libcnbpcmcm408.so

Code : Tout sélectionner

$ yaourt -Qo /usr/lib/libcnbpcmcm408.so
/usr/lib/libcnbpcmcm408.so is owned by cnijfilter-mg6300 3.80-5
$ pacman -Qo /usr/lib/libcnbpcmcm408.so
/usr/lib/libcnbpcmcm408.so is owned by cnijfilter-mg6300 3.80-5

Je veux mettre à jour avec le paquet sur AUR:

Code : Tout sélectionner

$ yaourt -S cnijfilter-mg6300

J'obtiens ensuite un

Code : Tout sélectionner

loading packages...
resolving dependencies...
looking for inter-conflicts...

Packages (1): cnijfilter-mg6300-3.80-6

Total Installed Size:   7.25 MiB
Net Upgrade Size:       -0.23 MiB

:: Proceed with installation? [Y/n] y

Donc visiblement l'ancien paquet est détecté. Ensuite:

Code : Tout sélectionner

$ yaourt -Qo /usr/lib/libcnbpcmcm408.so
error: No package owns /usr/lib/libcnbpcmcm408.so
$ pacman -Qo /usr/lib/libcnbpcmcm408.so
error: No package owns /usr/lib/libcnbpcmcm408.so

A tout hasard je viens d'essayer de créer le paquet à l'aide de yaourt et de l'installer avec pacman. Mais ça ne change rien.

J'ai également un .install avec

Code : Tout sélectionner

post_install() {
   if [ -x /sbin/ldconfig ]; then
      /sbin/ldconfig
   fi
}
post_upgrade() {
   post_install
}
post_remove() {
   post_install
}

J'ai essayé de le virer, mais rien n'y fait. Là je sèche.....

[benjarobin]

C'est normal, c'est /sbin/ldconfig qui recréer les liens symboliques... Pourquoi as tu fait une nouvelle version sans ceux-ci. Ils sont nécessaire !!!

Par contre je ne comprend pas tout. Si je fait :
- Suppression de l'ancien paquet
- Vérification que plus aucun fichier n'existe de l'ancien paquet
- Installation de la "-6" sans .install (donc pas de ldconfig exécuté lors de l'installation)
=> J'ai bien les liens symbolique de créé : C'est qui qui invoque ldconfig ?

Par exemple ce PKGBUILD

Code : Tout sélectionner

pkgname=foo-test
pkgver=1
pkgrel=2
pkgdesc="Test"
url=""
arch=('i686' 'x86_64')
license=('custom')

build() {

    cd "${srcdir}"
    # Copie une lib contenu à coté du PKGBUILD (C'est très moche, mais c'est pour un test)
    cp ../lib* libfootest.so.8.1
}

package() {
    cd "${pkgdir}"
    install -d ${pkgdir}/usr/lib/
    install -m 755 ${srcdir}/*so.* ${pkgdir}/usr/lib/
}

Alors une fois installé, il y a bien un lien symbolique (libfootest.so) qui est créé, mais celui-ci n'appartient pas au paquet

[Tristelune]

C'est normal, c'est /sbin/ldconfig qui recréer les liens symboliques... Pourquoi as tu fait une nouvelle version sans ceux-ci. Ils sont nécessaire !!!

Raisonnement archi basique. On m'a dit que le paquet cnijfilter-mg6100(lien) contenait aussi les liens symboliques lors d'une précédente version, mais qu'ils ont été supprimés par la suite. Je me suis dit que ça valait le coup d'essayer et ça a fonctionné sans ces liens. Je n'ai jamais pensé qu'ils étaient créés à côté. Je me rends bien compte maintenant pourquoi ça marche. Mais une chose que je ne comprends pas: pourquoi sont-ils nécessaires ? D'où le sais-tu ? C'est peut-être basique, mais je ne le sais pas. Pour que tu saches ou j'en suis: je ne sais plus ce que fais ldconfig. Donc certaines évidences pour toi sont des mystères pour moi .

Par contre je ne comprend pas tout. Si je fait :
- Suppression de l'ancien paquet
- Vérification que plus aucun fichier n'existe de l'ancien paquet
- Installation de la "-6" sans .install (donc pas de ldconfig exécuté lors de l'installation)
=> J'ai bien les liens symbolique de créé : C'est qui qui invoque ldconfig ?

J'avoue que pour l'instant je me concentre sur le début, je passerai à cette étape après...... Mais c'est peut-être pour ça que le paquet cnijfilter-mg6100 fonctionne.

[benjarobin]

Ils sont nécessaire dans le sens ou sinon il n'appartienne à aucun paquet : C'est moche
De plus tout dépend du binaire, ici ce n'est pas forcément le cas, mais il peut être compilé pour aller avec une libraire en .so sans version spécifique

Par contre ce que je ne savais pas, c'est que appeler ldconfig n'était pas nécessaire dans le .install, apparemment il est fait tout seul (par pacman ?)

[Tristelune]

Par contre ce que je ne savais pas, c'est que appeler ldconfig n'était pas nécessaire dans le .install, apparemment il est fait tout seul (par pacman ?)

A l'époque les pilotes ne fonctionnaient pas et c'est seulement après avoir appelé ldconfig que ça a fonctionné. Bon ça a tellement changé que peut-être entre-temps j'ai aussi modifié quelque chose. Quoi qu'il en soit, pour la question de fond c'est réglé. J'ai une autre question à présent, mais je fais un autre sujet. Merci!!!

[FoolEcho]

Par contre ce que je ne savais pas, c'est que appeler ldconfig n'était pas nécessaire dans le .install, apparemment il est fait tout seul (par pacman ?)

Ah tiens... en effet.
Du coup le ldconfig du .install ne sert plus ou fait redondance (vu que, dans tous les cas, ces liens sont orphelins à moins de les rajouter).

En fait, ce qui m'étonne ici (je n'ai pas regardé le détail de la compilation), est que la compilation ne génère pas ces liens... Tu as du zapper un truc sur le make install.

Hmmm... ... En fait le make install ne s'occupe pas de ça... Du coup, tu fais une copie manuelle mais tu oublies ces liens symboliques (je n'étais pas rentré à ce point dans le détail quand tu avais présenté ton PKGBUILD dans le passé, mais je comprends un peu mieux pourquoi à un moment il a fallu introduire le ldconfig ). Dans package(), tu as:

Code : Tout sélectionner

	# Install ${_id} libraries
	install -d ${pkgdir}/usr/lib/
	install -m 755 ${srcdir}/cnijfilter-source-${_pkgver}/${_id}/${_libdir}/*so.* ${pkgdir}/usr/lib/
	install -d ${pkgdir}/usr/lib/bjlib/
	install -m 644 ${srcdir}/cnijfilter-source-${_pkgver}/${_id}/database/* ${pkgdir}/usr/lib/bjlib/
	# Install common libraries
	install -m 755 ${srcdir}/cnijfilter-source-${_pkgver}/com/${_libdir}/*so.* ${pkgdir}/usr/lib/

Pour copier les liens plutôt que les recréer à la main (inutile ici car le lien symbolique est un chemin relatif), privilégie plutôt:

Code : Tout sélectionner

	install -d ${pkgdir}/usr/lib/
	cp -P ${srcdir}/cnijfilter-source-${_pkgver}/${_id}/${_libdir}/*so* ${pkgdir}/usr/lib/
	install -d ${pkgdir}/usr/lib/bjlib/
	install -m 644 ${srcdir}/cnijfilter-source-${_pkgver}/${_id}/database/* ${pkgdir}/usr/lib/bjlib/
	# Install common libraries
	cp -P ${srcdir}/cnijfilter-source-${_pkgver}/com/${_libdir}/*so* ${pkgdir}/usr/lib/

(attention à bien enlever le point après l'expression "so")
Ainsi les liens seront bien présents et appartenant à ton paquet (et plus besoin du .install).

[Tristelune]

Je viens de modifier le PKGBUILD en incluant les modifications que tu as indiquées. J'ai aussi viré le .install. L'imprimante fonctionne et je vois que les liens symboliques sont bien créés, mais qu'ils n'étaient pas copiés avant.
La raison est claire pourquoi ce n'était pas copié. Mais pourrais-tu m'aider sur ceci:

Pour copier les liens plutôt que les recréer à la main (inutile ici car le lien symbolique est un chemin relatif)

Je ne comprends pas ton argument. Qu'est-ce que ça aurait changé si ça avait été un chemin absolu ? Ma supposition: si ça avait été un chemin absolu, il se peut qu'il ne corresponde pas à l'arborescence du système. Dans ce cas, il aurait fallu en créer un autre. Et pour être complet pour de futurs PKGBUILD: est-ce à éviter les liens avec chemin absolu ?

Dans le cas où je fais fausse route, peut-être qu'un petit exemple pourra m'éclairer.

[FoolEcho]

Qu'est-ce que ça aurait changé si ça avait été un chemin absolu ? Ma supposition: si ça avait été un chemin absolu, il se peut qu'il ne corresponde pas à l'arborescence du système.

C'est ça.
Si le lien est fait en absolu, tu vas te retrouver avec le chemin du répertoire de construction du PKGBUILD ($srcdir ou $pkgdir). Du coup, à l'installation, ce lien n'aboutira pas où il faut.
Si je ne suis pas clair, il te suffit de faire un répertoire avec des liens symboliques absolu ou relatif (exemple pourri: un fichier toto.txt dans un répertoire test, ln -s ./toto.txt toto_relatif ; ln -s $PWD/toto.txt toto_absolu puis de déplacer ce répertoire).

Les chemins absolus sont à bannir l'essentiel du temps par manque de souplesse.

[Tristelune]

Là je pense que c'est clair. On peut donc clore le sujet. J'ai par la même occasion clos l'autre sujet.
Entre-temps je me suis rendu compte que quelqu'un a voté pour mon paquet cnijfilter-mg6300. Ca m'aurait fait plaisir
en temps normal, mais avec la version actuelle, il y a de fortes chance que j'ai mis la pagaille sur le système de quelqu'un d'autre

Je répare tout ça.

[FoolEcho]

mais avec la version actuelle, il y a de fortes chance que j'ai mis la pagaille sur le système de quelqu'un d'autre

Rien de dramatique. C'est AUR, hein, ça s'utilise à ces risques et périls (il est aussi arrivé et il arrive encore que des paquets officiels ne soient pas parfaits non plus).