Rapha�l 'SurcouF' Bordet a �crit :
S�bastien GALLET a �crit :
Et comme on est Vendredi ;-), alors je vous livre quelques reflexions
personnelles sur debian :
Les points noirs :
- pas de recompilation automatique des paquets ( en plus avec une
gestion des d�pendances comme celle de debian ca devrait pas �tre dur
� mettre en place).
Mauvaise distribution, changer de distribution, voir Gentoo.
Par contre, il existe un outil nomm� apt-build, mais est-ce bien utile ?
En outre, tu peux toujours t'amuser � monter un serveur buildd, si �a
t'amuse ;-)
Je me suis mont� une "ferme � paquet" pour java : j'ai besoin des
librairies java et de tomcat5, jboss et ...
Malheuresement, debian est tr�s pauvre
Quelques scripts, svn, cron et �a roule ...
- pas de scripts de tests automatiques.
Je ne comprends pas ta question.
Par exemple, dans chaque paquet rajouter un script. Dans le cas d'un
mta, son seul r�le est d'essayer d'envoyer un mail et de v�rifier que
celui est bien arriv� gr�ce aux logs.
C'est que je fais pour mes installations avec fai. D�s que
l'installation est termin�e, la machine reboote et le cron d�marre les test.
- debconf : cette base des registres dont je n'ai toujours pas compris
l'utilit� depuis 3 ans que je suis sous debian.
http://www.kitenet.net/~joey/debconf-debconf/tutorial-doc.html
Ce que je veux dire, c'est que je vois pas l'int�ret de centraliser une
partie de la configuration d'un programme � un endroit et le reste � un
autre. La derni�re fois que j'avais lu la doc sur debconf, il me semble
que j'avais lu qu'il ne fallait pas y stocker TOUS les param�tres de
configuration mais seulement certains.
Cela implique donc aux utilisateurs de configurer avec debconf et avec
les fichiers de configurations. De plus, les paquets ont diff�rentes
fa�ons de r�agir face a ce probl�me : par exemple, X refuse de se
reconfigurer par debconf si le fichier de conf a �t� modifi� � la main.
En revanche, xinet efface les modifications faites par l'utilisateur et
recr�e le sien.
- qualit� de certains paquets : certains scripts contiennent des
erreurs de d�butant : utilisation de scripts sans v�rifier leur
pr�sence. Je parle d'un probl�me r�cent qui avait une d�pendance sur
httpd et qui lan�ait /etc/init.d/apache dans le postinst. Forc�ment ca
marche pas avec apache2.
Si tous les utilisateurs de l'unstable comprenaient le r�le important
qui leur incombent en utilisant cette distribution, ils joueraient mieux
leur r�le de garde-fou. Maintenant, s'il s'agit de paquets de cette
distribution dont tu parles, alors, cet argument tombe en pi�ces.
J'essaye de limiter les risques avec testing. D'un autre cot�, il me
semble que c'est apache2 qui doit �tre dans sarge. Ca serait quand m�me
sympa que les d�veloppeurs utilisent aussi les paquets qui vont �tre
releas�.
- certains paquets sont des usines � gaz : quelqu'un a d�ja essay�
d'installer gforge ??? Pour ma part, j'ai essay� 2 fois en vain. j'ai
juste pass� 4 heures � tout remettre en marche : si comme moi vous
utilisez apache2, postgresl, postfix, ldap et sympa, un petit apt-get
install gforge et vous vous retrouvez avec apache, mysql, exim et
mailman et avec une base ldap cass�e.
A toi de faire attention � ce que tu fais avec apt. Apr�s tout, tu n'es
pas oblig� d'installer exim avec gforge si tu pr�cises que tu veux
gforge-mta-postfix (et tu noteras que tu as toujours sympa,, juste
mailman en plus, de m�me pour le couple apache/apache2. Putain, tu
utilises les m�mes logiciels que moi !). Mais j'avoue que gforge est �
r�server � un h�te d�di�. Par contre, c'est un cas particulier, pour ne
Quoi ??? Debian est un syst�me mono-applicatif ;-)
pas dire unique. Trouve donc un autre exemple.
J'avous que la premi�re je n'ai pas �t� tr�s malin ... et en plus j'ai
menti ... je n'ai m�me pas essay� de r�parer, j'ai directement relanc�
l'installation depuis fai et 25 minutes plus tard, j'avais un syst�me
tout beau tout neuf.
La deuxi�me fois que j'ai essay�, j'ai fait attention aux d�pendances et
je me suis restrouv� avec gforge � moiti� install� et ma base ldap
cass�e et postgresql qui refusait de d�marrer
- il serait interressant pour ce genre de paquets de s�parer
l'installation des paquets de la configuration (par la cr�ation d'un|
plusieurs paquet(s) de configuration).
Ce n'est pas un travail toujours facile et plut�t ingrat mais si tu veux
aider Roland Mas et Christian Bayle, ils seront ravis.
Que font-ils et ou peux t'on les joindre ?
- le syst�me de release : chaque version stable est tellement attendue
que d�s que la moindre rumeur de freeze arrive, les DD "poussent" les
paquets. Je les comprends tout � fait, � leur place je ferais la m�me
chose. Avec une version, tous les 2 ans, autant que les paquets soient
� jour quand la version sort. Il va bient�t falloir plus de temps pour
stabiliser debian que pour construire un pont ;-).
Disons que tous les d�veloppeurs debian ne se sentent, malheureusement,
pas toujours bien concern�s par la sortie de la nouvelle stable. La
version unstable leur convient et ils sont oblig�s de travailler avec
tous les jours... Des discussions, ouvertes, sur le sujet ont r�cemment
eu lieu comme je viens de l'�voquer dans un autre mail.
Pourquoi ils sont oblig�s d'utiliser unstable ???
- L'ajout une nouvelle version peut para�tre une bonne id�e mais dans
l'�tat actuel des choses, cela impliquera une surcharge de travail
cons�quente pour les DD : plus de release -> plus de paquets -> plus
de developpeurs -> plus de bogues -> moins de release -> cr�ation de
la frozing (entre la testing et la frozen) ...
AMHA, il faut que debian de modifie ses methodes de travail afin de
r�duire ses d�lais de stabilisation.
Je pense plut�t que frozen a sa place en tant que distribution.
Maintenant, tout ce qui bloque vraiment la sortie, c'est plus le manque
de personnel autour des auto-builders, car ils sont moins nombreux et le
poste demande certaines comp�tences, que le nombre de distributions d�j�
assez cons�quent. En effet, pour chaque nouvelle stable, il faut cr�er
une source de s�curit� pour celle-ci: cad, pour toutes les architectures
qu'elle supporte. Le nombre d'acc�s sur les h�tes des auto-builder ne
doit pas �tre tr�s grand et le temps des personnes qui s'en occupent
compl�tement rempli. S'il y a bien un point bloquant, c'est celui-ci.
si je prends mon exemple, je vais naturellement me tourner vers frozen
et abandonner testing. Et je pense que l'on va �tre bcp � le faire. Donc
testing ne servira plus � rien. ... et ...
Les points positifs :
- le g�nial fai qui permet d'installer et de configurer debian
automatiquement.
Il existe une m�thode similaire, bien que moins "packag�e", inspir� de
JumpStart (pour ceux qui connaissent Solaris) et nomm�e KickStart.
Evidemment, pour utiliser un serveur TFTP et tout le tromblon, faut le
faire soi-m�me, mais c'est possible.
j'ai utilis� kickstart (sous redhat) avant de passer � debian. Le seul
probl�me, c'est que c'est un binaire donc tr�s difficile � faire �voluer.
Il y a 3 ans, il etait incapable d'utiliser lvm ou xfs. Je pense qu'il a
du �voluer depuis. En revanche, fai est en scripts (perl, bash,
cfengine, ...) et en plus il utilise des hooks ce qui permet de
court-circuiter l'installation � n'importe quel momment.
- la constrution de paquets debian est plus souple (plusieurs fichiers
dans un r�pertoire) que celle de redhat (un seul fichier .spec) par
exemple.
plein d'autres. La preuve, je l'utilise.
...
Il n'existe qu'une m�thode pour construire un paquet RPM, le .spec.
Chez Debian, la m�thode debhelper est la plus populaire mais il en
existe pas mal d'autres, notamment cdbs. Tout cet attirail peut d�router
le d�butant s'il prend n'importe quel paquet pour exemple.
Sais-tu si il existe une m�thode pour construire des paquets avec ant ?
