[Linux] Debian Back to the future (was Re: Re : Ubuntu 6.10)

[Christophe Courtois]

Le Samedi 3 Mars 2007 02:07, Pierre THIERRY a écrit :
> >  Ah oui, tu peux... Mais c'est pas prévu dans le système actuel.
> En fait, si. Vu que le début de la procédure, c'est faire comme on fait
> déjà...

 Techniquement, oui.
 Techniquement, on pourrait tout faire. 
 C'est au niveau de la gestion de tout le bazar que ça bloquerait. 


> >  « Ça compile, ship it ! » 
> Ouais, comme maintenant. Je ne dis pas que c'est extraordinaire, mais ce
> n'est pas une régression en soi.

 Non, car actuellement, en upgradant le soft+ses librairies, tu testes le soft 
dans ce qui a des chances d'être l'environnement final, ie avec les 
librairies dans la version qui sera installée quand la distrib sera stable. 
 Dans cette logique, il est normal qu'une nouvelle version qui déboule dans 
unstable soit linkée par rapport aux librairies dans leur version la plus 
récente pour être TESTÉE et déboguée. 
 Par contre, la distrib est un tout, et s'en fiche des bugs nés de 
l'interaction entre un soft et une librairie qui ont 2 ans d'écart - ce sont 
des problèmes du monde proprio, ça.

 Le backport des softs de testing/unstable dans stable est quelque chose de 
bien moins testé que testing. Il y a des dépôts non officiels pour ça 
d'ailleurs, si tu y tiens, mais c'est parallèle à Debian.

> >  J'ai rien contre sur le principe, juste que l'utilité me semble
> >  relative quand l'option « recompiler » existe...
> Oui, mais recompiler oblige chaque utilisateur à faire quelque chose qui
> peut être fait de façon unique au sein de Debian. Parce que sinon,
> autant utiliser Gentoo.

 Avec Gentoo tu recompiles TOUT :o)  (quoique ça a paraît-il changé...)
 Quant au « chaque utilisateur » je suis sceptique : ceux qui sont en stable 
le sont parce qu'ils tiennent à leur stabilité, et ils ne vont pas la 
remettre en cause par des softs recompilés automatiquement « qui devraient 
passer » (et tu sais qu'avec les dépendances on ramène vite plus qu'un paquet 
ou deux ...) ; 
 ceux qui veulent du plus frais sont déjà sous testing (et justement, ils 
peuvent tester), ou Ubuntu ;
 ceux qui veulent quelques trucs ponctuel sur une stable peuvent recompiler 
depuis les sources Debian.

> >  Si tu remontes assez loin comme tu proposais, tu vas créer des bugs
> >  sur un soft en version 2006 qui pose problème s'il est compilé sur
> >  slink qui remonte au siècle dernier :o)   Réaliste ?
> Oui, parce que ça aura comme effet de bord d'améliorer la distrib, de la
> même façon que compiler sur 11 architectures participe de la qualité des
> softs de Debian (idem pour les ports Hurd et kFreeBSD).

 Non, Hurd et kFreeBSD sont des noyaux différents mais actuels. Compiler un 
soft de 2006 sur une libc et un kernel de 1998 que plus personne n'utilise 
(sauf application très ciblée ou machine « fossile » qui n'évolue plus), dont 
on sait que plein de bugs ont été corrigés, bôf bôf... 

> Pour certains paquets, ça permettra par exemple quelles API sont
> réellement nécessaires.

 Ce qui, pour la distrib, a un intérêt réduit, et réduit les tests. 
 (Je concède l'intérêt intellectuel, mais effectivement faut avoir du CPU à 
perdre pour savoir que les softs de unstable compilent avec toutes les 
versions de librairies qui ont traversé testing à un moment - tu fournis les 
serveurs ?)

> >  Tu sais, apt-build, c'est à peine plus long.
> Hum. L'autre soir, à l'IP, j'ai épaté ma libérée en installant Kino et
> ses codecs en une petite minute, téléchargement compris. À télécharger
> les sources et attendre que la compilation soit finie, je gage que ça
> aurait été moins probant.

 Je mettrais pas Debian à des « libérés » (quoique j'ai pas testé Etch sur un 
poste de travail), plutôt du Ubuntu, et là tu n'as pas le problème du système 
qui évolue trop lentement.

> Idem tous les jours quand je bosse. Si je m'aperçois qu'un outil me
> manque sur la machine où je suis, apt-get ou aptitude et quelques
> poignées de secondes plus tard, je suis de nouveau en train de
> travailler, avec l'outil en plus.

 As-tu essayé apt-build ? Faut pas longtemps pour recompiler une appli 
simple... (3 min sur une machine récente pour kino, download compris). Et en 
tout cas aucune intervention humaine.

> > Si, justement, pour ceux qui ont une stable mais veulent quelques
> > morceaux de testing en plus. Mais le gain pour quelques-uns ne vaut
> > pas le surcoût administratif.
> Le problème, c'est que ce n'est pas que quelques uns, je dirais. Ce
> serait utile à beaucoup de monde, notamment pour permettre d'avoir une
> machine très stable pour le péquin moyen tout en lui permettant d'avoir
> un ou deux outils dans une version récente. Ça permettrait d'installer
> les derniers jeux tout en ayant un poste de travail à l'épreuve des
> balles (ce qui est loin d'être le cas d'une testing avec de gros
> morceaux d'unstable...).

 Les dépôts non officiels sont là pour ça (Ubuntu aussi). 
 Et vus les problèmes de Debian pour sortir des versions stables dans des 
délais raisonnables, j'irais pas plus loin que dire que officialiser ou 
systématiser ces dépôts serait une bonne chose - mais cela prendra du temps, 
des ressources, des testeurs « en vie réelle » au projet. Backports.org, 
suggérait Steve, est un bon exemple. 

 Remarque, propose ça sur les listes Debian, ça aura peut-être son succès... 
Dans l'absolu c'est pas une mauvaise idée, mais justement en info j'ai appris 
à me méfier des idées trop générales. Vaut mieux un système simple maintenant 
que parfait dans une décennie (vieux débat).





-- 
Christophe Courtois
http://www.courtois.cc/
----------------------------------------------------------------------
The 'utf8' option requires that your system implements /dev/random,
however on Win32 platforms the system registry has been found to offer
equivalent functionality.
-- Documentation of perl package XML::Simpler