J'avais cru comprendre que c'était Advanced Packaging Tools donc une suite d'outils pour manipuler les paquets Debian.
Dans la pratique, je dirais que ça manipule surtout le repo. En gros, ça regarde dans une BDD texte les dépendances d'un paquet, ça les Dl, et ensuite ça invoque un gros "dpkg -i $pkgs". Ça peut aussi potentiellement faire de la collecte de déchets, aussi.
Mais le vrai boulot, in fine, c'est à dire dépaqueter le cadeau, exécuter les scripts pré/post rm/inst dans le bon ordre, déplacer les fichiers, mettre à jour (ou pas) les fichiers de conf... tout ça, c'est dpkg. Donc pour moi, c'est bien dpkg le gestionnaire, apt, apt-*, aptitude, synaptics (j'ai toujours un doute sur son nom à lui)... eux, c'est juste des frontaux.
Concernant les services, c'est presque la même histoire que pour les paquets. ;-)
Je me doute, mais sur ce point, ce que je voulais dire, c'est que j'ai opté pour une politique différente que celle que debian opte. Autrement dit: installer un paquet contenant un daemon ne l'active pas automatiquement. D'un autre côté, je me base sur runit, donc c'est trivial, alors que Debian s'est longtemps basée sur rc.d, j'imagine que ça joue.
Je reconnaît que ce point était hors sujet pour le coup :)
Doit-on considérer que le même code source compilé par 2 compilateurs est la même version ou non ? Qu'est-ce qu'une même version ? Code source identique ? Binaire identique ? Résultat identique ?
Je ne vois pas vraiment l'intérêt pour un utilisateur d'avoir, au niveau système, plusieurs build d'un programme avec plusieurs compilos... pour un développeur, ok, mais un programmeur fera de toute façon ses tests dans un dossier local.
Le seul moment ou je vois un problème potentiellement posé par la compilation d'un même source avec les mêmes options de build par un compilateur différent, c'est pour une bibliothèque dont l'ABI peut changer. Et ce problème est habituellement contourné par les bibliothèques elles-mêmes quand elles sont bien foutues (par exemple en utilisant pimpl).
Les 3 paquets sont fonctionnels en soi. Il n'y a pas de "coquilles vides". C'est juste que la définition du paquet gnupg-2 hérite de la définition du paquet gnupg.
J'ai peut-être mal compris ce qu'était un méta-paquet.
Je pense plutôt que c'est moi qui ne comprend pas à quoi sert ton héritage ni (hum... c'est chiant en vrai de faire un ou inclusif en langage parlé...) comment ça marche.
Pour le coup, ça me ferait plutôt penser aux «recommends» du format deb: tu peux installer un paquet parce qu'il améliorera le paquet courant, mais c'est pas obligatoire.
Sauf que du coup, c'est pas de l'héritage tel qu'entendu en POO, vu que dans ce cas ça serait une dépendance forte, donc un «depends».
Par contre, effectivement un meta-paquet c'est un paquet vide, qui se compose juste d'une série de dépendances d'un type ou d'un autre (debian utilise surtout des dépendances fortes, mais rien n'empêcherais un méta-paquet qui bannit).
Toujours est-il que Guix utilise plein de choses existantes ailleurs. Une partie de l'originalité est de les rassembler de manière cohérente.
Je trouve honnêtement le concept intéressant, mais pour moi sa plus grosse et principale force, c'est le fait qu'il semblerait invalider complètement une suite d'actions si une installation échoue, et ça, dpkg ne sait pas le faire, ses frontaux non plus.
Par contre, je me demande si la raison est vraiment le fait que nix/guix soient fonctionnels, justement.
En soit, le format des paquets deb devrais largement permettre sans trop de hacks un gestionnaire de paquet bien plus puissant (parallélisé, avec rollbacks, install en mode user), mais l'histoire est là.
[^] # Re: Mal connaître sa distribution
Posté par freem . En réponse à la dépêche Guix : un outil pour les remplacer tous. Évalué à 3.
Dans la pratique, je dirais que ça manipule surtout le repo. En gros, ça regarde dans une BDD texte les dépendances d'un paquet, ça les Dl, et ensuite ça invoque un gros "dpkg -i $pkgs". Ça peut aussi potentiellement faire de la collecte de déchets, aussi.
Mais le vrai boulot, in fine, c'est à dire dépaqueter le cadeau, exécuter les scripts pré/post rm/inst dans le bon ordre, déplacer les fichiers, mettre à jour (ou pas) les fichiers de conf... tout ça, c'est dpkg. Donc pour moi, c'est bien dpkg le gestionnaire, apt, apt-*, aptitude, synaptics (j'ai toujours un doute sur son nom à lui)... eux, c'est juste des frontaux.
Je me doute, mais sur ce point, ce que je voulais dire, c'est que j'ai opté pour une politique différente que celle que debian opte. Autrement dit: installer un paquet contenant un daemon ne l'active pas automatiquement. D'un autre côté, je me base sur runit, donc c'est trivial, alors que Debian s'est longtemps basée sur rc.d, j'imagine que ça joue.
Je reconnaît que ce point était hors sujet pour le coup :)
Je ne vois pas vraiment l'intérêt pour un utilisateur d'avoir, au niveau système, plusieurs build d'un programme avec plusieurs compilos... pour un développeur, ok, mais un programmeur fera de toute façon ses tests dans un dossier local.
Le seul moment ou je vois un problème potentiellement posé par la compilation d'un même source avec les mêmes options de build par un compilateur différent, c'est pour une bibliothèque dont l'ABI peut changer. Et ce problème est habituellement contourné par les bibliothèques elles-mêmes quand elles sont bien foutues (par exemple en utilisant pimpl).
Je pense plutôt que c'est moi qui ne comprend pas à quoi sert ton héritage ni (hum... c'est chiant en vrai de faire un ou inclusif en langage parlé...) comment ça marche.
Pour le coup, ça me ferait plutôt penser aux «recommends» du format deb: tu peux installer un paquet parce qu'il améliorera le paquet courant, mais c'est pas obligatoire.
Sauf que du coup, c'est pas de l'héritage tel qu'entendu en POO, vu que dans ce cas ça serait une dépendance forte, donc un «depends».
Par contre, effectivement un meta-paquet c'est un paquet vide, qui se compose juste d'une série de dépendances d'un type ou d'un autre (debian utilise surtout des dépendances fortes, mais rien n'empêcherais un méta-paquet qui bannit).
Je trouve honnêtement le concept intéressant, mais pour moi sa plus grosse et principale force, c'est le fait qu'il semblerait invalider complètement une suite d'actions si une installation échoue, et ça, dpkg ne sait pas le faire, ses frontaux non plus.
Par contre, je me demande si la raison est vraiment le fait que nix/guix soient fonctionnels, justement.
En soit, le format des paquets deb devrais largement permettre sans trop de hacks un gestionnaire de paquet bien plus puissant (parallélisé, avec rollbacks, install en mode user), mais l'histoire est là.
Enfin, l'histoire ainsi que le fait que le noyau linux (ou sont-ce extX les coupables?) ne permette pas, à ma connaissance, de réellement verrouiller un fichier: flock() places advisory locks only; given suitable permissions on a file, a process is free to ignore the use of flock() and perform I/O on the file. me font me demander d'à quel point nix/guix peuvent réellement garantir quoique ce soit.