RE: choisir son apt* et packager à l'arrache
Pour l’interrogation de la communauté Debian sur ce point, il y a peut-être d’autres listes plus adaptées (-devel notamment ?). Une autre manière de voir, c’est de regarder la popularité du paquet aptitude : https://qa.debian.org/popcon.php?package=aptitude Cdlt, Fred.
Re: choisir son apt* et packager à l'arrache
On Thu, Dec 14, 2023 at 09:44:37AM +, Frédéric BOITEUX wrote: > Pour moi, la commande « apt » est une interface plus conviviale et > unifiée que les anciens apt-get, apt-cache Ben vu le "gain" (c'est entre guillemet parce que c'est très discutable), je préfère continuer à utiliser les apt-tools pour la maintenance et aptitude ne me sert plus que pour chercher (mais le systeme de motifs est juste une des raisons de ma fidélité à debian et apt est une blague sur ce point). pouvoir écrire aptitude search '~Pmail-transport-agent !~i' pour voir la liste des alternatives à mon mta, par exemple, je trouve ça très utile. mais je me demande si la communauté debian a une position officielle sur ce point (et du coup je me demande comment leur poser la question). > Personnellement, le l’utilise pour les « apt update », « apt install > » ou lors des migrations via « apt upgrade » et « > apt full-upgrade » ajoute purge et autopurge et c'est tout ce que je fais avec apt. je continue a utiliser apt-cache directement. > [où il fonctionne correctement là où aptitude échoue la plupart du temps]. c'est la raison pour laquelle je n'utilise plus aptitude que pour faire de la recherche et de l'interrogation. > recherches poussées (je n’ai jamais trop tenté d’utiliser « apt » pour > cela) j'ai tenté :)) soit j'ai rien pigé, soit on est pas prets de pouvoir se débarasser d'aptitude. > beaucoup via son interface Curses (j’étais amateur de dselect > auparavant), il offre pas mal de fonctions interactives que apt n’a > pas… et qui excusent [pour moi] sa relative lenteur à > démarrer/terminer. j'avoue ne pas chercher d'excuses: il n'y a pas d'alternative à aptitude pour interroger l'état du systeme de paquets donc je prend. merci pour ton retour en tout cas. marc
RE: choisir son apt* et packager à l'arrache
Bonjour, Pour moi, la commande « apt » est une interface plus conviviale et unifiée que les anciens apt-get, apt-cache, etc. mais pas d’aptitude. Sa vocation était de présenter les infos de manière plus lisible à l’utilisateur, mais à ne pas utiliser dans des scripts. Personnellement, le l’utilise pour les « apt update », « apt install » ou lors des migrations via « apt upgrade » et « apt full-upgrade » [où il fonctionne correctement là où aptitude échoue la plupart du temps]. J’utilise aptitude à la fois pour ses recherches poussées (je n’ai jamais trop tenté d’utiliser « apt » pour cela), pour installer des paquets dans des scripts, mais également beaucoup via son interface Curses (j’étais amateur de dselect auparavant), il offre pas mal de fonctions interactives que apt n’a pas… et qui excusent [pour moi] sa relative lenteur à démarrer/terminer. Cordialement, Fred.
choisir son apt* et packager à l'arrache
salut à tous, je passe un thread sur la liste parce que j'aimerais beaucoup avoir votre position (à jour) sur le sujet. il y a qq années, il semblait que apt était sensé devenir l'interface officielle des apt-tools sauf que * j'ai l'impression que c'est tjrs aussi mauvais comparé à aptitude * aptitude a un vrai pb de lenteur > > > > > J'avais pas rsvg-convert, apt me dit que c'est dans le paquet > > > > > python3-sphinxcontrib.svg2pdfconverter. Ca me surprend un peu mais ça > > > > > a > > > > > effectivement corrigé le problème. Normal ? > > > > > > > > $ apt-file search rsvg-convert > > > > librsvg2-bin: /usr/bin/rsvg-convert > > > > librsvg2-bin: /usr/share/man/man1/rsvg-convert.1.gz > > > C'est dommage parce que quand on fait > > > apt search rsvg-convert > > > python3-sphinxcontrib.svg2pdfconverter/stable,stable 1.2.2-1 all > > >Sphinx SVG to PDF Converter Extension > > > > C'est un des trucs qui me saoule dans debian: apt est sensé devenir *le > > frontend* de tous les apt-tools sauf qu'il pue du bec. > > > > du coup: > > * apt pour installer > > * aptitude et apt-file pour chercher au passage je tiens à signaler que: * les motifs de recherche de aptitude sont une des raisons de ma fidélité à debian comme seule distro potable pour un desktop user-end. * j'aimerais bien dire "aptitude partout" était responsable du seul foirage de mise a jour majeure en 20 ans sur debian (entre temps j'ai découvert les images openstack avec leurs dépendances à la con donc on va dire 2). * aptitude est lent au démarrage, il arrive avec une ui et un tetris, le tout ne m'ayant évidement jamais servi. > > > > il faut que je fasse un paquet debian pour que les gens > > > > aient juste à faire "apt install". > > > > > > Pas obligatoire, c'est l'occasion de leur montrer apt search et apt-file > > > jeudi : sauf démonstration du contraire, je continue à dire qu'il ne *faut pas uitliser apt search* mais aptitude ou apt-cache. > > c'est une très mauvaise pratique: faire des apt install de partout pour > > ne plus savoir pourquoi tu as installé tel et tel paquet. > > > > l'avantage de faire apt install mon-tp1 mon-tp2, c'est que rsvg-convert > > sera désinstallé le jour ou tu n'as plus aucun tp qui en dépend. > première option parce que c'est ce que les personnes vont très > majoritairement rencontrer dans leurs activités (combien de projets de > recherche viennent avec des jolis paquets ?). les "jolis paquets" (qualité debian, remonté dans upstream) sont chiants à faire et c'est la raison pour laquelle personne ne prend le temps de les faire. faire un paquet avec une liste de dépendances et qqs fichiers prets à l'emploi est trivial et on devrait faire la promotion de cette pratique. J'utilisais equivs pour faire mes paquets et j'utilise maintenant mkcrapdeb https://git.unistra.fr/mc/mkcrapdeb je suis à l'affut de bonnes pratiques/pratiques officielles pour ce ce packaging simple. a+ marc
