[Linux-bruxelles] Etre "Open" ou pas

[Jerome Warnier]

Gilles Douillet wrote:

>>Ce qui fait que même si tu es content d'un logiciel, tu es obligé de
>>prendre son successeur pour les nouvelles installations, et accepter
>>tous les problèmes des nouvelles versions (y compris, parfois, le fait
>>de ne pas pouvoir traiter tels-quels les anciens formats de fichiers.
>>Les administrateurs systèmes en ont des cauchemars, rien qu'avec les
>>"upgrade-path" des éditeurs.
>>
>
>J'aimerais répondre en disant que l'upgrade même en linux c'est tout aussi
>problématique.. rien que pour RPM (pour le DEB je sais pas ...) ou l'on
>passe du RPM 3 au RPM 4, donc pour mettre à jour sa jolie RedHat 6.2 ou sa
>belle slackware 8.1  (une des meilleures) c'est un peu chiant si on trouve
>pas des RPM 3 (enfin le gars qui s'y connait un peu sait faire lui-même ses
>RPM à partir de tar.gz)
>Aussi, pourquoi avoir changer le filesystem, de /usr/doc vers
>/usr/share/doc... génial pour les packages qui n'ont pas été refaits (bon on
>va me répondre que c'est du libre et qu'il y a toujours une personne qui va
>s'en occuper mais comme le disait Fred, s'il arrète le développement de Gaby
>.. hein comment on fait ???) et puis s'ils ont été refaits dans quelle
>version et avec quelle lib ?
>
Sous UNIX, le fait de fusionner /usr/doc et /usr/share/doc ne pose pas 
vraiment de problèmes, les liens symboliques sont faits pour.
De plus, il est peu probable que cet exemple précis casse quoi que ce 
soit. A part les manpages, ton programme fontionnera tjs aussi bien 
qu'avant.

>La vraiment je crois que même en, linux, et logiciel libre, l'upgrade reste
>problématique, bête example, client dhcpcd 0.70 (libc5) vers dhcpcd 1.0
>(glibc) <---génial le plan ... Donc on se rend compte que finalement même en
>logiciel libre on est très tenu par les distributions....
>OK en Debain on a apt-get, Jérôme parlait de trois minutes pour la glibc ..
>mais combien de temps pour une application spécifique du système ... plus
>bien sur toutes les dépendences ???
>
C'est pour cela surtout qu'il existe des systèmes de packages. Les 
dépendances sont gérées automatiquement. Certains sont supérieurs à 
d'autres, et RPM n'est certainement pas un exemple à suivre.
La transition de RPM 3 vers RPM 4 ne pose pas plus de problèmes que 
cela, les packages RPM 3 étant toujours utilisables avec l'utilitaire et 
les librairies RPM 4.
La seule chose vraiment navrante dans cet "upgrade" est que le nouveau 
format est quasiment inutilisable sans l'outil lui-même.
Les anciennes versions, comme les .deb, étaient des archives qu'il était 
facile d'extraire avec des outils UNIX tout-à-fait standards.

>Bête example aussi ... on a le kernel et ses modules ..que faire quand le
>support d'un truc est pas prévu en 2.2 pas même en module externe .. (on
>passe en 2.4 je sais) mais alors la l'upgrade va durer combien de temps ???
>
Là, tu parles de modifications hardwares. On n'est donc plus dans le 
software.
Par contre, tu peux toujours utiliser (presque) tous les programmes que 
tu utilisais avec les anciens kernels et tu sais que cela restera vrai.
Dans le monde du logiciel propriétaire, ce n'est clairement pas le cas: 
même des programmes tournant sous Win95 ne tournent plus du tout sous 
WinME, qui est pourtant basé sur la même chose (à ce que dit MS, puisque 
personne n'a le droit de vérifier!).