La deuxième chose est que Guix (originellement Nix) est un changement de paradigme. Un gestionnaire de paquets comme APT peut être vu comme "impératif" tandis que Guix comme "fonctionnel". Tout ca avec des très gros guillemets ! :-)
À ce stade la, on est loin des guillemets...
DPKG (nope, APT n'est pas un gestionnaire de paquets, il se contente de télécharger un paquet et ses dépendances) est majoritairement "déclaratif" c'est à dire basé sur un simple fichier de configuration.
Pour rappel, un .deb, c'est une archive cpio qui contiens 3 fichiers: 1 fichier texte qui décris la version, 1 tarball avec les méta-données qui sont toutes, à ma connaissance, sous forme de texte déclaratif (ini-style) à l'exception des scripts pré/post rm/inst, et une tarball contenant les données.
Je sais que la compression est supportée, mais je ne sais exactement comment.
Quelques paquets utilisent en effet des scripts pré/post rm/inst, mais à mes yeux et rapport a ce que j'ai subi, c'est soit une erreur politique (gérer automatiquement les services plutôt que les faire gérer par l'install/suppression de paquets qui seraient en conflits) soit un workaround pour ces foutus sgbdr qui sont incapables de fournir des données binaires (faut reconstruire a partir d'un dump sql... long, lourd et pénible).
À noter qu'au taf, j'ai opté pour la création de paquets qui activent les services qu'on écrit, et qui sont parfois en conflit. Ben, c'est vachement plus simple qu'écrire les scripts pré/post inst/rm, et s'il nous venais l'envie d'utiliser systemd plutôt que runit, il n'y aurait pas besoin de refaire (et donc réinstaller) les paquets contenant les binaires: les paquets de services sont, en effet, à part.
Concrètement, que signifie 3 fois la même version ? Est-ce que la version libfoo-1.2.3 compilé par GCC 7 ou GCC 8 ou autre signifie la même version pour vous ?
Tout dépend de si GCC 7 et GCC 8 ont la même ABI. Si c'est pas le cas, c'est en effet le job de distro de gérer.
Mais bon, hé, vraiment, mauvais exemple ici (a moins que tu aies un bug causé par une incompat entre ces compilos?), tu aurais dû parler de GCC vs Clang, ou de la glibc vs musl. La réponse aurait été que, majoritairement, la différence de libc se sens, la différence de compilo C, non. Ah, je précise bien, de compilo C, pour les autres langages, c'est plus compliqué, d'où le modèle «hour-glass» pour construire des libs portables en C++, notamment.
Pour info, sache que, il y a 8 ans (quand j'étais sous win), on étais capables d'avoir des ABI compatibles sous windows entre GCC et VisualC++. Et ça fait longtemps que j'ai pas eu de problèmes parce que j'utilise un compilo différent de celui du système (pas sûr d'en avoir déjà eu)? Dans une certaine mesure, même utiliser une libc différente m'est pas mal transparent.
Par ailleurs, Guix a aussi la notion d'héritage (inherit) pour un paquet.
L'équivalent d'un méta-paquet qui dépend au choix d'un ou plusieurs paquets, ou l'équivalent d'un paquet qui fournit un paquet virtuel? Non, parce que bon, Debian implémente ça depuis que je m'en sers, soit au moins 10 ans.
[^] # Re: Mal connaître sa distribution
Posté par freem . En réponse à la dépêche Guix : un outil pour les remplacer tous. Évalué à 2.
À ce stade la, on est loin des guillemets...
DPKG (nope, APT n'est pas un gestionnaire de paquets, il se contente de télécharger un paquet et ses dépendances) est majoritairement "déclaratif" c'est à dire basé sur un simple fichier de configuration.
Pour rappel, un .deb, c'est une archive cpio qui contiens 3 fichiers: 1 fichier texte qui décris la version, 1 tarball avec les méta-données qui sont toutes, à ma connaissance, sous forme de texte déclaratif (ini-style) à l'exception des scripts pré/post rm/inst, et une tarball contenant les données.
Je sais que la compression est supportée, mais je ne sais exactement comment.
Quelques paquets utilisent en effet des scripts pré/post rm/inst, mais à mes yeux et rapport a ce que j'ai subi, c'est soit une erreur politique (gérer automatiquement les services plutôt que les faire gérer par l'install/suppression de paquets qui seraient en conflits) soit un workaround pour ces foutus sgbdr qui sont incapables de fournir des données binaires (faut reconstruire a partir d'un dump sql... long, lourd et pénible).
À noter qu'au taf, j'ai opté pour la création de paquets qui activent les services qu'on écrit, et qui sont parfois en conflit. Ben, c'est vachement plus simple qu'écrire les scripts pré/post inst/rm, et s'il nous venais l'envie d'utiliser systemd plutôt que runit, il n'y aurait pas besoin de refaire (et donc réinstaller) les paquets contenant les binaires: les paquets de services sont, en effet, à part.
Tout dépend de si GCC 7 et GCC 8 ont la même ABI. Si c'est pas le cas, c'est en effet le job de distro de gérer.
Mais bon, hé, vraiment, mauvais exemple ici (a moins que tu aies un bug causé par une incompat entre ces compilos?), tu aurais dû parler de GCC vs Clang, ou de la glibc vs musl. La réponse aurait été que, majoritairement, la différence de libc se sens, la différence de compilo C, non. Ah, je précise bien, de compilo C, pour les autres langages, c'est plus compliqué, d'où le modèle «hour-glass» pour construire des libs portables en C++, notamment.
Pour info, sache que, il y a 8 ans (quand j'étais sous win), on étais capables d'avoir des ABI compatibles sous windows entre GCC et VisualC++. Et ça fait longtemps que j'ai pas eu de problèmes parce que j'utilise un compilo différent de celui du système (pas sûr d'en avoir déjà eu)? Dans une certaine mesure, même utiliser une libc différente m'est pas mal transparent.
L'équivalent d'un méta-paquet qui dépend au choix d'un ou plusieurs paquets, ou l'équivalent d'un paquet qui fournit un paquet virtuel? Non, parce que bon, Debian implémente ça depuis que je m'en sers, soit au moins 10 ans.