> Il y aussi la possibilité d'avoir temporairement les deux librairies en
> même temps et de supprimer n'ancienne une fois que tout est
> mise à jours.
C'est en gros l'idée des approches les plus réalistes qui ont été proposées. En gros, on conserverait au fil des installation de paquets compilés un cache de dépendances de librairies. Lors d'une mise à jour libtoto-1.0->1.1, le libtoto-1.0.so ne serait supprimé que si il n'est plus référencé dans le cache. Sinon, il serait conservé et rajouté au contenu référencé par libtoto-1.1, pour être éventuellement nettoyé lors d'une future mise à jour 1.1->1.2 par exemple.
> Mais j'ai peur que certains paquets utilisent l'ancienne
> librairie même s'ils sont reconstruits avec la présence de la
> nouvelle librairie.
C'est un truc auquel il faudrait faire gaffe, mais ça peut être fixé par les ebuilds quand un paquet à tendance à se comporter comme ça, donc c'est pas vraiment bloquant.
Enfin bref, tout ça pour dire que ce problème est effectivement assez naturel sur une distrib source, mais qu'il y aurait moyen de le traiter quand même.
> Ce n'est pas parce que la distribution est binaire qu'elle est figée.
> C'est uniquement une question de gestion de projet.
Oui, je suis plutôt d'accord. Enfin avec un bémol : je pense que l'approche source, parceque justement les dépendances y sont un peu plus souples que celles des paquets binaires, facilite un peu le dynamisme au sein d'une branche stable. Avec des paquets binaires, à cause des dépendances de lib + strictes, tu as plus souvent à faire des commits groupés (typiquement, avec une lib, les programmes qui y sont linkés). Mais ça reste très envisageable, et je pense qu'il y a encore une place à prendre pour une distrib binaire qui ne serait pas orientée releases et qui ne serait pas pour autant une branche de développement. C'est peu être un peu le cas de debian testing, qui si j'ai bien compris passe quand même par une certaine dose de QA, même si elle n'est pas officiellement "stable" (enfin j'dis ça, je connais pas bien, je sais pas par exemple si ils s'imposent que testing soit égale sur toutes les archis ou si, comme gentoo, les différentes archis évoluent chacune à son rythme).
> L'avantage de Fedora, est de pouvoir "tout casser" par moment
> pour avancer vite sans grosse prise de tête avec la compatibilité
> la fiabilité.
> C'est la même chose avec les Linux de numéro impair.
En fait sous gentoo tu peux te permettre ça aussi sur un groupe d'ebuilds que tu hard-masques. Et une fois l'ensemble prêt, les paquets passent en ~arch avec des dépendances qui forcent l'update de l'ensemble tout d'un coup pour rester cohérent. Mais bon, ouais, c'est quand même un peu moins souple.
[^] # Re: Qlqs compléments
Posté par tgl . En réponse au journal [Long] Expérience Gentoo. Évalué à 3.
> même temps et de supprimer n'ancienne une fois que tout est
> mise à jours.
C'est en gros l'idée des approches les plus réalistes qui ont été proposées. En gros, on conserverait au fil des installation de paquets compilés un cache de dépendances de librairies. Lors d'une mise à jour libtoto-1.0->1.1, le libtoto-1.0.so ne serait supprimé que si il n'est plus référencé dans le cache. Sinon, il serait conservé et rajouté au contenu référencé par libtoto-1.1, pour être éventuellement nettoyé lors d'une future mise à jour 1.1->1.2 par exemple.
> Mais j'ai peur que certains paquets utilisent l'ancienne
> librairie même s'ils sont reconstruits avec la présence de la
> nouvelle librairie.
C'est un truc auquel il faudrait faire gaffe, mais ça peut être fixé par les ebuilds quand un paquet à tendance à se comporter comme ça, donc c'est pas vraiment bloquant.
Enfin bref, tout ça pour dire que ce problème est effectivement assez naturel sur une distrib source, mais qu'il y aurait moyen de le traiter quand même.
> Ce n'est pas parce que la distribution est binaire qu'elle est figée.
> C'est uniquement une question de gestion de projet.
Oui, je suis plutôt d'accord. Enfin avec un bémol : je pense que l'approche source, parceque justement les dépendances y sont un peu plus souples que celles des paquets binaires, facilite un peu le dynamisme au sein d'une branche stable. Avec des paquets binaires, à cause des dépendances de lib + strictes, tu as plus souvent à faire des commits groupés (typiquement, avec une lib, les programmes qui y sont linkés). Mais ça reste très envisageable, et je pense qu'il y a encore une place à prendre pour une distrib binaire qui ne serait pas orientée releases et qui ne serait pas pour autant une branche de développement. C'est peu être un peu le cas de debian testing, qui si j'ai bien compris passe quand même par une certaine dose de QA, même si elle n'est pas officiellement "stable" (enfin j'dis ça, je connais pas bien, je sais pas par exemple si ils s'imposent que testing soit égale sur toutes les archis ou si, comme gentoo, les différentes archis évoluent chacune à son rythme).
> L'avantage de Fedora, est de pouvoir "tout casser" par moment
> pour avancer vite sans grosse prise de tête avec la compatibilité
> la fiabilité.
> C'est la même chose avec les Linux de numéro impair.
En fait sous gentoo tu peux te permettre ça aussi sur un groupe d'ebuilds que tu hard-masques. Et une fois l'ensemble prêt, les paquets passent en ~arch avec des dépendances qui forcent l'update de l'ensemble tout d'un coup pour rester cohérent. Mais bon, ouais, c'est quand même un peu moins souple.