Re: disgression [était : Backport]
Le Tue, 27 Nov 2001 21:01:27 -0500, laurent.pelecq@soleil.org écrivait :
> Il y a plusieurs solutions pour avoir « des softs récents sans casser
> les machines » sur potato qui ont déjà été expliquées (/usr/local,
> /usr/local+stow, chroot). Tu veux absolument le rétro-portage des
> paquets. Plusieurs personnes pensent que c'est trop couteux. Tu
> appelles ça du mépris si tu veux.
>
Tu n'as pas tord mais tu n'as pas raison (PK, the mew Salomon King :-)).
Reprenons un peu depuis le début en essayant de dédramatiser le débat.
Les insultes ne servent à rien si ce n'est de s'enfermer chacun dans sa
tour d'ivoire sans faire avancer le débat.
Quel est le *vrai* problème ?
Le problème est l'utilisation de Debian dans un milieu professionnel.
J'entends par là un milieu où lorsque l'on installe Debian, on est
redevable de compte à une entité supérieure qui attend :
1. Que cela fonctionne correctement
2. Que cela fonctionne toujours
Jusque là, tout le monde est d'accord avec moi. Bon, généralement,
lorsque l'on installe du logiciel libre dans un milieu disons un peu
rétif à cela, comme le monde de l'entreprise, le gars qui vend cela,
généralement l'admin de service, engage sa responsabilité dans l'affaire
pour obtenir du Grand Chef l'autorisation de le faire. Rien de nouveau
sous le soleil. Le Grand Chef va donc, contrairement à l'habitude, se
défosser de *toutes* ses responsabilités sur le gars qui a pris en
charge le bousin.
Dans la plupart des cas, ce n'est pas un problème. Le système est
stable, la distribution est sure et sinon se met à jour pour le devenir.
De ce côté, mis à part une possible défaillance dans la configuration du
système, il n'y a pas de soucis. D'ailleurs, c'est même plutôt peinard
(et reconnu comme tel)...
Or, le problème connu et reconnu de Debian est son immense inertie lors
d'un passage entre deux versions. Pour un serveur, pas de problème. Une
fois en production, on n'y touche pas ou peu. Pour une station de
travail, c'est un autre problème... Les utilisateurs, tout à fait
légitimement, sont en droit d'avoir leurs outils de travail à jour. Les
raisons sont variées mais la meilleure reste quand même que la dernière
version à jour est généralement plus performante (et moins
boguée :-))...
Seulement, voilà : deux ans entre deux versions de Debian, cela
représente un gouffre entre entre deux versions de logiciels intégrés.
Prenons l'exemple de Mozilla : la M18 (16 ?) est dans Potato et on en
est à la 0.9.6 aujourd'hui. L'une est une version alpha (et encore, je
suis gentil :-)) et l'autre est relativement performante, en tout cas,
utilisable au quotidien. Normal, il y a deux ans de développement dans
l'intervalle.... Vous me direz : « il y a Netscape dans la Potato...» et
je vous répondrai « oui. mais Netscape est HS aujourd'hui pour un grand
nombre de sites... De plus, l'exemple est juste pour.. l'exemple
justement. ».
Bon, encore une fois, tout le monde ici est d'accord avec moi.
Quelle est la solution apportée par Debian pour régler ce problème ?
La seule « officielle » est d'utiliser la version testing de Debian, une
version moins instable que unstable car on y ajouté quelques contraintes
(15 jours de vie d'un paquet dans unstable sans bogue pour passer dans
testing). C'est une solution sympa, qui a le mérite de faire pré-tester
la distribution sans trop de risques à un grand nombre de volontaires
non développeur et cela permet certainement à Debian de continuer sa
quête qui est de faire le système le plus homogène et le plus stable
(cohérent en tout cas) possible.
Seulement, le « hic » est que cela n'est pas compatible avec le monde de
l'entreprise...
Je m'explique : une entreprise n'en a rien à secoué de jouer les
bétâ-testeurs. Au contraire... Le p'tit gars qui a pris la
responsabilité - que dis-je - qui engagé sa responsabilité personnelle
- et qui joue donc son boulot dans l'affaire - ne peut se permettre
d'utiliser une version non stable. Je sais que c'est difficile à
comprendre pour un certain nombre de gens ici, notamment les gens qui
n'ont pas trop de contacts avec le monde du privé. C'est un monde où
l'on se fait mettre à la porte sur *une* erreur de jugement (on appelle
cela une faute professionnelle). Et personnellement, je pense que toute
personne utilisant une version non stable de Debian (ou autre) dans une
entreprise fait une faute (en tout cas, le patron le prendra comme
tel).
Quand on en est là, on a deux choix. Soit on se couvre le cul via une
entreprise qui ouvre le parapluie (Microsoft, Solaris) à sa place, soit
on persévère et on continue à proner le libre. Entendez bien que dans la
seconde voie, le gars qui continue *prend des risques*. Il n'est
peut-être pas développeur, ni même rapporteur de bogue mais il engage
son boulot dans l'affaire. Et franchement, ce n'est pas rien.... et
l'insulter (ou le juger) parce qu'il n'est ni développeur ni rapporteur
de bogue est déplacé. Quand on joue son métier parce qu'on y croit, cela
force le respect... Tout le monde ne peut pas travailler pour une boite
qui croit au libre et qui connait ses contraintes.
J'admire les développeurs Debian et le temps consacrés à leur tâche.
Modestement (très !), j'essaie de participer. Mais un développeur fait
ce qu'il veut... et il arrête quand il veut (c'est la première règle...
On ne peut forcer... gnagnagna... etc.). Mais un gars qui vend à son
entreprise Debian en engageant *sa* responsabilité, engage son travail -
et donc son garde-manger et l'éducation des gamins -. La portée n'est
pas tout à fait la même.
Bon, la disgression était longue mais c'est pour recadrer tout. Debian
n'existe pas sans les développeurs mais in fine n'a aucun intérêt, si ce
n'est intellectuel, si personne ne l'utilise.
Bref, retournons à notre problème de migration. Que va faire notre petit
admin dans son coin quand l'utilisateur lambda va lui dire que sylpheed
est bogué parce qu'il quote comme un porc dans sa version 0.6.4 ? Son
rôle - on rappelle que l'informatique sert de support et est au service
de l'entreprise - est de corriger cet état de fait, dans la mesure du
possible. Coup de bol, la version 0.6.5 corrige cela... mais n'est
disponible que dans testing. Sans faire de faute professionnelle, il ne
peut raisonnablement pas passer l'utilisateur lambda sur testing...
Alors comment faire ? Encore deux solutions...
1. La solution Slack de l'admin-tant-pis-pour-l'avenir : je compile, je
mets dans /usr/local et on verra plus tard... La solution stow est
pis-aller qui essaie vaille que vaille de ne pas trop crader une
solution un peu crade...
2. La solution : j'ai un système qui a une philosophie d'usage et je la
conserve...
Bon, devinez où va ma préférence :-). Sans déconner, l'ajout d'un paquet
n'importe comment dans un système gérés par un gestionnaire de paquet
est une douce hérésie... sans compter la cohérence pour gérer plus d'une
machine... On n'aime le boulot *bien fait* ou pas. Dans le premier cas,
c'est généralement le premier critère de choix d'une Debian :-)
Donc, en partant là-dessus, le rétroportage du paquet devient une
nécessité. Attention, cela n'est valable que pour certains paquets, la
plupart du temps des utilitaires. Du coup, la quête (du graal) de
Georges se trouve justifier (même si son ironie grinçante peut
déplaire...). Bon, on peut aussi recréer un paquet « from scratch » ce
qui est un peu idiot vu que le travail est déjà fait.
Quelle est la politique de Debian là-dedans ?
Peu ou prou, Debian s'en fout et s'en remet aux développeurs. Ces
derniers, au cas par cas, s'arrangent pour que leur paquet se rétroporte
plus ou moins facilement. Il faut avouer que suivant le paquet à charge,
c'est plus ou moins trivial à faire. Quand je dis « Debian s'en
fout... », ce n'est pas tout à fait exact. La dernière version d'apt
possède justement une option (apt-get source -b) qui permet de faciliter
ce rétroportage. C'est un premier pas vers cette solution - mais c'est
un pas timide puisque dans la Debian Policy, rien n'oblige le
développeur à la favoriser -. On peut espérer que la demande aidant,
cette solution prenne plus d'importance et que le développement future
de Debian l'intégre (dans la mesure du possible). Après tout, Rome ne
s'est pas faite en un jour...
Bref, pour conclure, on peut dire qu'il y a deux mondes qui s'affrontent
sans trop se comprendre. D'un côté, on a le pragmatisme de l'entreprise
pour qui ni la philosophie ni rien d'autre ne justifient une entorse à
la productivité. De l'autre, on a le libre qui va cahin-caha et fait son
bonhomme de chemin sans trop se soucier du pragamtisme précédent. La
liaison entre les deux n'est pas évidente à faire et il faudra que
chacun fasse un petit bout de chemin vers l'autre pour marcher ensemble.
Après tout, on travaille tous pour cela, non ?
Un dernier mot (désolé :-)). Le problème est *réel*. Debian n'a pas
l'habitude de se voiler la face. Donc, la question à se poser est :
« Est-ce que Debian veut se positionner dans le monde de
l'entreprise¹ ? ». Si Debian (j'entends par là, la communauté des
développeurs, s'en fout - et c'est son droit - qu'elle l'annonce
clairement. Sinon, la quête de Georges est légitime et cela ne sert à
rien de l'envoyer balader, si ce n'est pour qu'il y mette peut-être plus
de forme (mais, bon, cela risque de ne plus être Georges ainsi...).
PK, bavard
¹: entreprise type grosse structure bien sûr, là où rien n'est simple à
obtenir, sauf les emmerdes.
--
Patrice KARATCHENTZEFF
STMicroelectronics Tel: 04-76-92-67-95
850, rue Jean Monnet
38926 CROLLES Cedex, France Courriel: patrice.karatchentzeff@st.com
Reply to: