[namcap] PKGBUILD pour paquets python dans AUR (nouveau)

Mise à jour / Création /debug de paquetages
Avatar de l’utilisateur
rafmav
yeomen
Messages : 271
Inscription : mer. 11 mars 2009, 13:30

[namcap] PKGBUILD pour paquets python dans AUR (nouveau)

Message par rafmav »

Bonjour,

Si namcap dit qu'un paquet est inclus mais pas nécessaire, je peux le supprimer sans problème de la liste des dépendances dans le PKGBUILD ? Même si c'est du python ?
Est-ce que namcap est utile et fiable concernant les paquets python ?

Cf ci-dessous, après création du paquet, avant installation bien sûr :

Code : Tout sélectionner

$ namcap ~/.cache/yay/python-librosa/python-librosa-0.7.1-1-any.pkg.tar.xz 
python-librosa W: Dependency included and not needed ('python-numpy')
python-librosa W: Dependency included and not needed ('python-scipy')
python-librosa W: Dependency included and not needed ('python-six')
python-librosa W: Dependency included and not needed ('python-numba')
python-librosa W: Dependency included and not needed ('python-soundfile')
python-librosa W: Dependency included and not needed ('python-joblib')
python-librosa W: Dependency included and not needed ('python-matplotlib')
python-librosa W: Dependency included and not needed ('python-audioread')
python-librosa W: Dependency included and not needed ('python-decorator')
python-librosa W: Dependency included and not needed ('python-scikit-learn')
python-librosa W: Dependency included and not needed ('python-resampy')
Merci d'avance.

PS: Je récupère des paquets dans AUR quand je n'ai pas le choix, puis j'essaye de voir si je peux supprimer certaines dépendances ou "downgrader" celles-ci.
Ppar exemple, un autre paquet dont j'ai oublié le nom requiert llvm8 qui est dans AUR, mais en réalité llvm semble suffire -pas encore testé- et est dans les dépôts officiels fonctionne, etc. Et je sais que souvent on a tendance à mettre dans PKGBUILD, dans la liste des dépendances, plus de paquets que prévus ou de version plus haute que nécessaire, "pourvu que ça marche", en omettant ensuite de vérifier...
#rmv$@f29£8µ1
Ma petite paresse me perdra...
Si vous ne voulez pas vous tromper, ne faites rien!
Impossible est impossible: est venue une personne qui ne savais pas que c'était impossible, et qui l'a fait!
Avatar de l’utilisateur
papajoke
Elfe
Messages : 773
Inscription : sam. 30 août 2014, 19:54

Re: [namcap] PKGBUILD pour paquets python dans AUR (nouveau)

Message par papajoke »

bonjour

Bien sûr que ces paquets python sont obligatoire pour faire tourner cette librairie
Le développeur donne le détail dans son setup.py : une librairie python est à l'origine faite pour être installée via pip donc le développeur donne toujours un arbre de dependence très précis
Arch stable - Kde 5 / zsh - btrfs/mbr - Intel Core i3 - 6Go RAM - GeForce 405 video-nouveau
Avatar de l’utilisateur
rafmav
yeomen
Messages : 271
Inscription : mer. 11 mars 2009, 13:30

Re: [namcap] PKGBUILD pour paquets python dans AUR (nouveau)

Message par rafmav »

Ok merci

Alors pourquoi namcap ne les retrouve pas en vérifiant le paquet une fois le paquet créé ?

Impossible que les créateurs de namcap ignore cela, namcap est programmé en python3 donc en python...

Par précaution:
- je prends autant que possible les paquets officiels, en priorité ceux dans core, extra et community, ensuite éventuellement dans multilib (paquets 32 bits essentiellement, donc de moins en moins) et dans archlinuxfr.
- j'évite le plus possible les paquets AUR, non officiels, et parfois je modifie pour moi les PKGBUILD, en supprimant certaines dépendances, en espérant que ça marche.
- je n'installe aucun programme ou paquet autrement que par pacman ou yay (successeur de yaourt).
Ainsi, je n'ai jamais de problèmes, ou presque.
- je sais utiliser pip, j'évite de m'en servir pour les raisons invoquées ici (idem pour tous les trucs style docker ou autre).
- j'avais vu que dans le wiki, et le setup.py, les dépendances étaient déclarées nécessaires.

Entre ce qu'un ou plusieurs programmeurs déclarent comme dépendances, où que ce soit, et les dépendances réellement utiles une fois le logiciel créé, il y a un pas... comme font "certains" (tous ?) programmeurs: mettre tous les paquets que l'on pense utile en dépendance pendant la programmation, pour ne pas être ennuyé avec ça, puis omission de vérifier ensuite quels paquets en dépendances sont finalement et réellement utiles: impossible de leur reprocher, "pourvu que ça marche"!

Et donc si namcap ne convient pas, y a t'il un autre outil, autre que les tests et essais sans les dépendances ?

Dans l'exemple présent, en plus verbeux :

Code : Tout sélectionner

$ namcap -i ~/.cache/yay/python-librosa/python-librosa-0.7.1-1-any.pkg.tar.xz 
python-librosa I: Script link detected (python) in file ['usr/lib/python3.8/site-packages/librosa/util/files.py', 'usr/lib/python3.8/site-packages/librosa/__init__.py', 'usr/lib/python3.8/site-packages/librosa/core/fft.py', 'usr/lib/python3.8/site-packages/librosa/util/exceptions.py', 'usr/lib/python3.8/site-packages/librosa/filters.py', 'usr/lib/python3.8/site-packages/librosa/util/deprecation.py', 'usr/lib/python3.8/site-packages/librosa/core/harmonic.py', 'usr/lib/python3.8/site-packages/librosa/segment.py', 'usr/lib/python3.8/site-packages/librosa/core/audio.py', 'usr/lib/python3.8/site-packages/librosa/feature/spectral.py', 'usr/lib/python3.8/site-packages/librosa/feature/inverse.py', 'usr/lib/python3.8/site-packages/librosa/effects.py', 'usr/lib/python3.8/site-packages/librosa/beat.py', 'usr/lib/python3.8/site-packages/librosa/core/spectrum.py', 'usr/lib/python3.8/site-packages/librosa/sequence.py', 'usr/lib/python3.8/site-packages/librosa/feature/rhythm.py', 'usr/lib/python3.8/site-packages/librosa/core/time_frequency.py', 'usr/lib/python3.8/site-packages/librosa/util/decorators.py', 'usr/lib/python3.8/site-packages/librosa/util/_nnls.py', 'usr/lib/python3.8/site-packages/librosa/util/matching.py', 'usr/lib/python3.8/site-packages/librosa/decompose.py', 'usr/lib/python3.8/site-packages/librosa/util/utils.py', 'usr/lib/python3.8/site-packages/librosa/output.py', 'usr/lib/python3.8/site-packages/librosa/util/__init__.py', 'usr/lib/python3.8/site-packages/librosa/onset.py', 'usr/lib/python3.8/site-packages/librosa/core/constantq.py', 'usr/lib/python3.8/site-packages/librosa/core/pitch.py', 'usr/lib/python3.8/site-packages/librosa/_cache.py', 'usr/lib/python3.8/site-packages/librosa/feature/__init__.py', 'usr/lib/python3.8/site-packages/librosa/core/__init__.py', 'usr/lib/python3.8/site-packages/librosa/display.py', 'usr/lib/python3.8/site-packages/librosa/version.py', 'usr/lib/python3.8/site-packages/librosa/feature/utils.py']
python-librosa W: Dependency included and not needed ('python-numpy')
python-librosa W: Dependency included and not needed ('python-scipy')
python-librosa W: Dependency included and not needed ('python-six')
python-librosa W: Dependency included and not needed ('python-numba')
python-librosa W: Dependency included and not needed ('python-soundfile')
python-librosa W: Dependency included and not needed ('python-joblib')
python-librosa W: Dependency included and not needed ('python-matplotlib')
python-librosa W: Dependency included and not needed ('python-audioread')
python-librosa W: Dependency included and not needed ('python-decorator')
python-librosa W: Dependency included and not needed ('python-scikit-learn')
python-librosa W: Dependency included and not needed ('python-resampy')
python-librosa I: Dependency covered by dependencies from link dependence (linux-api-headers)
python-librosa I: Dependency covered by dependencies from link dependence (libutil-linux)
python-librosa I: Dependency covered by dependencies from link dependence (tzdata)
python-librosa I: Dependency covered by dependencies from link dependence (keyutils)
python-librosa I: Dependency covered by dependencies from link dependence (iana-etc)
python-librosa I: Dependency covered by dependencies from link dependence (gcc-libs)
python-librosa I: Dependency covered by dependencies from link dependence (krb5)
python-librosa I: Dependency covered by dependencies from link dependence (ncurses)
python-librosa I: Dependency covered by dependencies from link dependence (openssl)
python-librosa I: Dependency covered by dependencies from link dependence (zlib)
python-librosa I: Dependency covered by dependencies from link dependence (filesystem)
python-librosa I: Dependency covered by dependencies from link dependence (libncursesw.so)
python-librosa I: Dependency covered by dependencies from link dependence (gdbm)
python-librosa I: Dependency covered by dependencies from link dependence (perl)
python-librosa I: Dependency covered by dependencies from link dependence (expat)
python-librosa I: Dependency covered by dependencies from link dependence (libsasl)
python-librosa I: Dependency covered by dependencies from link dependence (libnsl)
python-librosa I: Dependency covered by dependencies from link dependence (libtirpc)
python-librosa I: Dependency covered by dependencies from link dependence (e2fsprogs)
python-librosa I: Dependency covered by dependencies from link dependence (sh)
python-librosa I: Dependency covered by dependencies from link dependence (db)
python-librosa I: Dependency covered by dependencies from link dependence (bzip2)
python-librosa I: Dependency covered by dependencies from link dependence (libffi)
python-librosa I: Dependency covered by dependencies from link dependence (libldap)
python-librosa I: Dependency covered by dependencies from link dependence (readline)
python-librosa I: Dependency covered by dependencies from link dependence (glibc)
python-librosa I: Depends as namcap sees them: depends=(python)
Et donc namcap semble bien être capable de repérer les paquets utiles des autres ?

Eventuellement, une fois le paquet installé, regarder du côté de "ldd" qui "indique quels objets partagés (librairies partagées) sont requises par chaque programme ou objet spécifié sur la ligne de commande", mais le fait-il pour les programmes en python ? Supposons que oui !

Heureusement (ou malheureusement ?), une fois un paquet installé, si des dépendances déclarées comme requises sont déja installées, ça va fonctionner, que lesdites dépendances soient utilisées ou non par le programme. Et pas des instructions "pacman" de recherche dépendances, "pacman" ne faisant que, et c'est normal, vérifier en fonction de sa base de données, peu importe si les dépendances sont finalement utilisées par un progamme ou non... ???
D'où question 2, à part un "chroot" compliqué où le paquet que l'on veut tester aura accès à tout SAUF aux dépendances dont on veut voir s'il peut s'en passer... Existe-t'il quelque chose de simple permettant de limiter l'accès, pour tel ou tel programme, à uniquement la liste des dépencances qu'il a déclaré ? ça peut aussi être une sécurité supplémentaire ... ?
#rmv$@f29£8µ1
Ma petite paresse me perdra...
Si vous ne voulez pas vous tromper, ne faites rien!
Impossible est impossible: est venue une personne qui ne savais pas que c'était impossible, et qui l'a fait!
Avatar de l’utilisateur
papajoke
Elfe
Messages : 773
Inscription : sam. 30 août 2014, 19:54

Re: [namcap] PKGBUILD pour paquets python dans AUR (nouveau)

Message par papajoke »

rafmav a écrit : mar. 18 févr. 2020, 10:37 Et donc namcap semble bien être capable de repérer les paquets utiles des autres ?
Si tu regardes le dépot , il y a justement des modifications pour détecter les dépendances python qui ne sont pas encore dans le version classique. Je suppose donc qu'il y a un problème ...
Arch stable - Kde 5 / zsh - btrfs/mbr - Intel Core i3 - 6Go RAM - GeForce 405 video-nouveau
Répondre