Re: Inertie de Debian était : packages debian
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 ?
Reply to: