> Mais je maintiens que l'integration, c'est un choix, et un choix ca fait plaisir ou ca fache.
Ta concèption de l'intégration m'échappe.
Imaginons que je fasse un programme. Au début il n'est qu'en source et en .tar.gz.
Pour quelle raison je ne ferais pas le travail d'intégration qui consiste a écrire un fichier .spec pour rpm (ou le fichier .bidule pour deb) ?
Si je ne le fais pas, ce n'est pas car l'intégration c'est mal, mais pour d'autres raisons : je n'ai pas les compétences, je n'ai pas le temps, etc.
Refuser l'intégration pour refuser l'intégration, je ne comprend pas.
> Je ne suis pas lie a une version pour avoir mon bind 9.5.x ou apache 1.3, 2.0 ou 2.2 (and co)
Ça c'est un autre problème qui n'est pas lié à l'intégration. Fedora peut parfaitement fournir apache 1.3, 2.0 et 2.2 à la fois. Il n'y a pas de problème technique significatif.
Si Fedora ne le fait pas, ce n'est pas à cause de l'intégration. Fedora ne le fait pas car ce n'est pas dans sa philosophie (Fedora veut être très proche des développements en cours et il n'est pas dans ses objectifs de fournir du (futur) "has been"). De même, Fedora pourrait fournir plusieurs versions de python ou perl. Mais ce n'est pas dans la philosophie de Fedora. Les choses se passent ainsi avec Fedora :
- pour la prochaine Fedora, il est, par exemple, décidé de passer de perl 5 à perl 6
- Perl 5 est viré de la branche de développement, Perl 6 est ajouté
- tous les scripts qui ne marchent pas en perl 5 sont corrigés (idéalement en travaillant avec l'upstream).
- test via les différentes beta de la prochaine Fedora.
- sortie de la nouvelle Fedora uniquement avec perl 6 (et c'est fait exprès !)
Sur le moment ça peut paraitre beaucoup de boulot (et c'est beaucoup de boulot). Mais sur le long terme c'est plus efficace de qu'avoir à maintenir différentes versions de perl et de scripts qui utilisent différentes versions de Perl.
Enfin Fedora n'est pas une distribution qui "se suffit" en général. Son support est trop cours pour un usage en serveur sérieux. Nombres de contributeur à Fedora ont une RHEL/Centos en parallèle.
Enfin founir apache 1.3, apache 2.0, etc à la fois est maintenant limite sans intérêt avec la virtualisation. D'autant que c'est principalement pour gérer l'existant. Sur ma F10 toute fraiche, j'ai une machine virtuelle avec RHEL 3 (apache 2.0 mais surtout php 4). Ça me prend 256 Mo de ram. Machine virtuelle que j'avais aussi sous mon ancienne F8. RHEL 3 qui était avant sur un ancien serveur (un PIII). J'ai seulement copié le disque sur un périphérique loop, fait quelques ajustements, puis utilisé libvirt. Pour passer de F8 à F10, j'ai seulement copier l'image de la machine virtuelle. Et voila.
Sur mon F10 j'ai aussi une machine virtuelle Centos 5 pour test avant de mettre en production les modifications (mise à jour au autre) sur EC2.
[^] # Re: A propos ...
Posté par IsNotGood . En réponse au journal Je suis passé sous FreeBSD ça y est !. Évalué à 1.
Ta concèption de l'intégration m'échappe.
Imaginons que je fasse un programme. Au début il n'est qu'en source et en .tar.gz.
Pour quelle raison je ne ferais pas le travail d'intégration qui consiste a écrire un fichier .spec pour rpm (ou le fichier .bidule pour deb) ?
Si je ne le fais pas, ce n'est pas car l'intégration c'est mal, mais pour d'autres raisons : je n'ai pas les compétences, je n'ai pas le temps, etc.
Refuser l'intégration pour refuser l'intégration, je ne comprend pas.
> Je ne suis pas lie a une version pour avoir mon bind 9.5.x ou apache 1.3, 2.0 ou 2.2 (and co)
Ça c'est un autre problème qui n'est pas lié à l'intégration. Fedora peut parfaitement fournir apache 1.3, 2.0 et 2.2 à la fois. Il n'y a pas de problème technique significatif.
Si Fedora ne le fait pas, ce n'est pas à cause de l'intégration. Fedora ne le fait pas car ce n'est pas dans sa philosophie (Fedora veut être très proche des développements en cours et il n'est pas dans ses objectifs de fournir du (futur) "has been"). De même, Fedora pourrait fournir plusieurs versions de python ou perl. Mais ce n'est pas dans la philosophie de Fedora. Les choses se passent ainsi avec Fedora :
- pour la prochaine Fedora, il est, par exemple, décidé de passer de perl 5 à perl 6
- Perl 5 est viré de la branche de développement, Perl 6 est ajouté
- tous les scripts qui ne marchent pas en perl 5 sont corrigés (idéalement en travaillant avec l'upstream).
- test via les différentes beta de la prochaine Fedora.
- sortie de la nouvelle Fedora uniquement avec perl 6 (et c'est fait exprès !)
Sur le moment ça peut paraitre beaucoup de boulot (et c'est beaucoup de boulot). Mais sur le long terme c'est plus efficace de qu'avoir à maintenir différentes versions de perl et de scripts qui utilisent différentes versions de Perl.
Enfin Fedora n'est pas une distribution qui "se suffit" en général. Son support est trop cours pour un usage en serveur sérieux. Nombres de contributeur à Fedora ont une RHEL/Centos en parallèle.
Enfin founir apache 1.3, apache 2.0, etc à la fois est maintenant limite sans intérêt avec la virtualisation. D'autant que c'est principalement pour gérer l'existant. Sur ma F10 toute fraiche, j'ai une machine virtuelle avec RHEL 3 (apache 2.0 mais surtout php 4). Ça me prend 256 Mo de ram. Machine virtuelle que j'avais aussi sous mon ancienne F8. RHEL 3 qui était avant sur un ancien serveur (un PIII). J'ai seulement copié le disque sur un périphérique loop, fait quelques ajustements, puis utilisé libvirt. Pour passer de F8 à F10, j'ai seulement copier l'image de la machine virtuelle. Et voila.
Sur mon F10 j'ai aussi une machine virtuelle Centos 5 pour test avant de mettre en production les modifications (mise à jour au autre) sur EC2.