et il est souvent plus
simple de se refaire un paquet à partir des sources que d'adapter les
paquets sid à la stable.
et il est souvent plus
simple de se refaire un paquet à partir des sources que d'adapter les
paquets sid à la stable.
et il est souvent plus
simple de se refaire un paquet à partir des sources que d'adapter les
paquets sid à la stable.
Hmm, c'est Vendredi.
En fait tout dépend de l'utilisation de la machine et de la situation
[...]
Une solution pourrait être de vaguement officialiser cela en créant un
dépot de paquet récent (bof) ou bien en s'arrangeant pour que les
paquets sources de testing voire sid puissent systématiquement être
recompilés sur la woody. L'impossibilité quasi systématique de
recompiler un paquet sid sur une woody me parait le problème le plus
gênant et il est souvent plus simple de se refaire un paquet à partir
des sources que d'adapter les paquets sid à la stable. Le problème est
que cela fige un peu les utilitaires de construction des paquets.
4) Le serveur. Personnellement, la stable me parait indispensable, mais
des besoins parfois importants peuvent être nécéssaires (typiquement
spassassin). La testing est une erreur car il n'y a pas de mis à jour de
sécurité sur la testing je crois. La possibilité de recompiler
ponctuellement facilement un paquet est ou plutôt serait intéressante.
Le plus lésé dans la situation actuelle est le particulier qui veut à la
fois une machine stable ET les logiciels dernier cri.
Hmm, c'est Vendredi.
En fait tout dépend de l'utilisation de la machine et de la situation
[...]
Une solution pourrait être de vaguement officialiser cela en créant un
dépot de paquet récent (bof) ou bien en s'arrangeant pour que les
paquets sources de testing voire sid puissent systématiquement être
recompilés sur la woody. L'impossibilité quasi systématique de
recompiler un paquet sid sur une woody me parait le problème le plus
gênant et il est souvent plus simple de se refaire un paquet à partir
des sources que d'adapter les paquets sid à la stable. Le problème est
que cela fige un peu les utilitaires de construction des paquets.
4) Le serveur. Personnellement, la stable me parait indispensable, mais
des besoins parfois importants peuvent être nécéssaires (typiquement
spassassin). La testing est une erreur car il n'y a pas de mis à jour de
sécurité sur la testing je crois. La possibilité de recompiler
ponctuellement facilement un paquet est ou plutôt serait intéressante.
Le plus lésé dans la situation actuelle est le particulier qui veut à la
fois une machine stable ET les logiciels dernier cri.
Hmm, c'est Vendredi.
En fait tout dépend de l'utilisation de la machine et de la situation
[...]
Une solution pourrait être de vaguement officialiser cela en créant un
dépot de paquet récent (bof) ou bien en s'arrangeant pour que les
paquets sources de testing voire sid puissent systématiquement être
recompilés sur la woody. L'impossibilité quasi systématique de
recompiler un paquet sid sur une woody me parait le problème le plus
gênant et il est souvent plus simple de se refaire un paquet à partir
des sources que d'adapter les paquets sid à la stable. Le problème est
que cela fige un peu les utilitaires de construction des paquets.
4) Le serveur. Personnellement, la stable me parait indispensable, mais
des besoins parfois importants peuvent être nécéssaires (typiquement
spassassin). La testing est une erreur car il n'y a pas de mis à jour de
sécurité sur la testing je crois. La possibilité de recompiler
ponctuellement facilement un paquet est ou plutôt serait intéressante.
Le plus lésé dans la situation actuelle est le particulier qui veut à la
fois une machine stable ET les logiciels dernier cri.
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 ;-)
- pas de scripts de tests automatiques.
Je ne comprends pas ta question.
- 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
- 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.
- 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
pas dire unique. Trouve donc un autre exemple.
- 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.
- 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.
- 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.
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.
- 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.
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 ;-)
- pas de scripts de tests automatiques.
Je ne comprends pas ta question.
- 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
- 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.
- 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
pas dire unique. Trouve donc un autre exemple.
- 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.
- 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.
- 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.
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.
- 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.
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 ;-)
- pas de scripts de tests automatiques.
Je ne comprends pas ta question.
- 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
- 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.
- 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
pas dire unique. Trouve donc un autre exemple.
- 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.
- 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.
- 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.
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.
- 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.
Hmm, c'est Vendredi.
Une solution pourrait être de vaguement officialiser cela en créant un
dépot de paquet récent (bof) ou bien en s'arrangeant pour que les paquets
sources de testing voire sid puissent systématiquement être recompilés sur
la woody. L'impossibilité quasi systématique de recompiler un paquet sid
sur une woody me parait le problème le plus gênant et il est souvent plus
simple de se refaire un paquet à partir des sources que d'adapter les
paquets sid à la stable. Le problème est que cela fige un peu les
utilitaires de construction des paquets.
3) Une machine de production (typiquement salle de cours). Là, la
stabilité est la plus importante l'installation doit surtout être
reproductible.
4) Le serveur. Personnellement, la stable me parait indispensable, mais
des besoins parfois importants peuvent être nécéssaires (typiquement
spassassin). La testing est une erreur car il n'y a pas de mis à jour de
sécurité sur la testing je crois. La possibilité de recompiler
ponctuellement facilement un paquet est ou plutôt serait intéressante.
François Boisson
Hmm, c'est Vendredi.
Une solution pourrait être de vaguement officialiser cela en créant un
dépot de paquet récent (bof) ou bien en s'arrangeant pour que les paquets
sources de testing voire sid puissent systématiquement être recompilés sur
la woody. L'impossibilité quasi systématique de recompiler un paquet sid
sur une woody me parait le problème le plus gênant et il est souvent plus
simple de se refaire un paquet à partir des sources que d'adapter les
paquets sid à la stable. Le problème est que cela fige un peu les
utilitaires de construction des paquets.
3) Une machine de production (typiquement salle de cours). Là, la
stabilité est la plus importante l'installation doit surtout être
reproductible.
4) Le serveur. Personnellement, la stable me parait indispensable, mais
des besoins parfois importants peuvent être nécéssaires (typiquement
spassassin). La testing est une erreur car il n'y a pas de mis à jour de
sécurité sur la testing je crois. La possibilité de recompiler
ponctuellement facilement un paquet est ou plutôt serait intéressante.
François Boisson
Hmm, c'est Vendredi.
Une solution pourrait être de vaguement officialiser cela en créant un
dépot de paquet récent (bof) ou bien en s'arrangeant pour que les paquets
sources de testing voire sid puissent systématiquement être recompilés sur
la woody. L'impossibilité quasi systématique de recompiler un paquet sid
sur une woody me parait le problème le plus gênant et il est souvent plus
simple de se refaire un paquet à partir des sources que d'adapter les
paquets sid à la stable. Le problème est que cela fige un peu les
utilitaires de construction des paquets.
3) Une machine de production (typiquement salle de cours). Là, la
stabilité est la plus importante l'installation doit surtout être
reproductible.
4) Le serveur. Personnellement, la stable me parait indispensable, mais
des besoins parfois importants peuvent être nécéssaires (typiquement
spassassin). La testing est une erreur car il n'y a pas de mis à jour de
sécurité sur la testing je crois. La possibilité de recompiler
ponctuellement facilement un paquet est ou plutôt serait intéressante.
François Boisson
La stabilité d'une debian se mesure *surtout* dans la stabilité du
système de paquet : en clair des dépendances. Donc que tu ne puisse pas
recompiler facilement un paquet sid en stable me semble logique.
La stabilité d'une debian se mesure *surtout* dans la stabilité du
système de paquet : en clair des dépendances. Donc que tu ne puisse pas
recompiler facilement un paquet sid en stable me semble logique.
La stabilité d'une debian se mesure *surtout* dans la stabilité du
système de paquet : en clair des dépendances. Donc que tu ne puisse pas
recompiler facilement un paquet sid en stable me semble logique.
Le Fri, 17 Dec 2004 19:38:56 +0100
Sylvain Sauvage a écrit:
> La stabilité d'une debian se mesure *surtout* dans la stabilité du
> système de paquet : en clair des dépendances. Donc que tu ne puisse
> pas recompiler facilement un paquet sid en stable me semble logique.
Non, on peut faire du développement sur du stable. Je conçois la
stabilité comme une arborescence de paquets stables (les noeuds) sur
lesquels on accroche des paquets terminaux qui, eux, peuvent venir de
l'instable. Je suis sous woody et j'ai compilé sylpheed-1.00beta4
(disponible chez moi d'ailleurs) pour avoir des fonctionnalités
importantes: le reply-to-liste n'existe pas dans le sylpheed de la
woody. Je suis en train de concevoir les machines pour un concours de
recrutement important. Je pense les mettre sous Debian/woody car je ne
veux pas avoir le moindre souci de réseau/gestionnaire de fenêtres/etc
mais pour les logiciels utilisés par les candidats, il me faut des
versions récentes et c'est pour ça que j'ai fait des paquets de maxim a,
axiom, scilab-3.0 (avec un bug corrigé), etc. Ces paquets sont terminaux
dans le sens où aucun autre paquet n'a besoin d'eux. Il est quand même
curieux qu'on ne puisse pas recompiler simplement ces paquets sous
woody. Une solution serait peut être de classifier les paquets en
fonction de leur statut (noeud ou feuille) dans l'arborescence des
paquets et éventuellement de leuyr profondeur. On pourrait alors
demander des exigences plus importantes dans la recompilation pour des
paquets terminaux.
Le Fri, 17 Dec 2004 19:38:56 +0100
Sylvain Sauvage <Sylvain.Sauvage@metanoesis.net> a écrit:
> La stabilité d'une debian se mesure *surtout* dans la stabilité du
> système de paquet : en clair des dépendances. Donc que tu ne puisse
> pas recompiler facilement un paquet sid en stable me semble logique.
Non, on peut faire du développement sur du stable. Je conçois la
stabilité comme une arborescence de paquets stables (les noeuds) sur
lesquels on accroche des paquets terminaux qui, eux, peuvent venir de
l'instable. Je suis sous woody et j'ai compilé sylpheed-1.00beta4
(disponible chez moi d'ailleurs) pour avoir des fonctionnalités
importantes: le reply-to-liste n'existe pas dans le sylpheed de la
woody. Je suis en train de concevoir les machines pour un concours de
recrutement important. Je pense les mettre sous Debian/woody car je ne
veux pas avoir le moindre souci de réseau/gestionnaire de fenêtres/etc
mais pour les logiciels utilisés par les candidats, il me faut des
versions récentes et c'est pour ça que j'ai fait des paquets de maxim a,
axiom, scilab-3.0 (avec un bug corrigé), etc. Ces paquets sont terminaux
dans le sens où aucun autre paquet n'a besoin d'eux. Il est quand même
curieux qu'on ne puisse pas recompiler simplement ces paquets sous
woody. Une solution serait peut être de classifier les paquets en
fonction de leur statut (noeud ou feuille) dans l'arborescence des
paquets et éventuellement de leuyr profondeur. On pourrait alors
demander des exigences plus importantes dans la recompilation pour des
paquets terminaux.
Le Fri, 17 Dec 2004 19:38:56 +0100
Sylvain Sauvage a écrit:
> La stabilité d'une debian se mesure *surtout* dans la stabilité du
> système de paquet : en clair des dépendances. Donc que tu ne puisse
> pas recompiler facilement un paquet sid en stable me semble logique.
Non, on peut faire du développement sur du stable. Je conçois la
stabilité comme une arborescence de paquets stables (les noeuds) sur
lesquels on accroche des paquets terminaux qui, eux, peuvent venir de
l'instable. Je suis sous woody et j'ai compilé sylpheed-1.00beta4
(disponible chez moi d'ailleurs) pour avoir des fonctionnalités
importantes: le reply-to-liste n'existe pas dans le sylpheed de la
woody. Je suis en train de concevoir les machines pour un concours de
recrutement important. Je pense les mettre sous Debian/woody car je ne
veux pas avoir le moindre souci de réseau/gestionnaire de fenêtres/etc
mais pour les logiciels utilisés par les candidats, il me faut des
versions récentes et c'est pour ça que j'ai fait des paquets de maxim a,
axiom, scilab-3.0 (avec un bug corrigé), etc. Ces paquets sont terminaux
dans le sens où aucun autre paquet n'a besoin d'eux. Il est quand même
curieux qu'on ne puisse pas recompiler simplement ces paquets sous
woody. Une solution serait peut être de classifier les paquets en
fonction de leur statut (noeud ou feuille) dans l'arborescence des
paquets et éventuellement de leuyr profondeur. On pourrait alors
demander des exigences plus importantes dans la recompilation pour des
paquets terminaux.
Ce qui me semble logique, c'est que les paquets-feuilles dépendent des
n_uds internes et de certaines versions particulières de ces n_uds. Ces
n_uds internes sont d'ailleurs souvent des bibliothèques. Si tu veux
changer la version d'une feuille, tu te retrouves à avoir à changer
aussi les n_uds. D'ailleurs, les n_uds aussi évoluent.
Je t'accorde que, parfois (c'est difficilement quantifiable comme
fréquence), les dépendances de version entre une feuille et les n_uds
internes sont trop fortes car ce sont celles qu'a utilisé le responsable
(donc, en général, celle qui est en Sid à ce moment-là) et pas la
version minimale nécessaire.
Je comprends aussi que le changement des règles° dh* soit aussi parfois
gênant mais c'est assez difficile de figer ce genre de système.
(° : Je dis « règles » car utilisées dans le fichier debian/rules ;o)
Ce qui me semble logique, c'est que les paquets-feuilles dépendent des
n_uds internes et de certaines versions particulières de ces n_uds. Ces
n_uds internes sont d'ailleurs souvent des bibliothèques. Si tu veux
changer la version d'une feuille, tu te retrouves à avoir à changer
aussi les n_uds. D'ailleurs, les n_uds aussi évoluent.
Je t'accorde que, parfois (c'est difficilement quantifiable comme
fréquence), les dépendances de version entre une feuille et les n_uds
internes sont trop fortes car ce sont celles qu'a utilisé le responsable
(donc, en général, celle qui est en Sid à ce moment-là) et pas la
version minimale nécessaire.
Je comprends aussi que le changement des règles° dh* soit aussi parfois
gênant mais c'est assez difficile de figer ce genre de système.
(° : Je dis « règles » car utilisées dans le fichier debian/rules ;o)
Ce qui me semble logique, c'est que les paquets-feuilles dépendent des
n_uds internes et de certaines versions particulières de ces n_uds. Ces
n_uds internes sont d'ailleurs souvent des bibliothèques. Si tu veux
changer la version d'une feuille, tu te retrouves à avoir à changer
aussi les n_uds. D'ailleurs, les n_uds aussi évoluent.
Je t'accorde que, parfois (c'est difficilement quantifiable comme
fréquence), les dépendances de version entre une feuille et les n_uds
internes sont trop fortes car ce sont celles qu'a utilisé le responsable
(donc, en général, celle qui est en Sid à ce moment-là) et pas la
version minimale nécessaire.
Je comprends aussi que le changement des règles° dh* soit aussi parfois
gênant mais c'est assez difficile de figer ce genre de système.
(° : Je dis « règles » car utilisées dans le fichier debian/rules ;o)
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).
- pas de scripts de tests automatiques.
- debconf : cette base des registres dont je n'ai toujours pas compris
l'utilité depuis 3 ans que je suis sous debian.
- qualité de certains paquets : certains scripts contiennent des erreur s
de débutant : utilisation de scripts sans vérifier leur présence. J e
parle d'un problème récent qui avait une dépendance sur httpd et qu i
lançait /etc/init.d/apache dans le postinst. Forcément ca marche pas
avec apache2.
- 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.
- 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).
- 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 ;-).
- 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.
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).
- pas de scripts de tests automatiques.
- debconf : cette base des registres dont je n'ai toujours pas compris
l'utilité depuis 3 ans que je suis sous debian.
- qualité de certains paquets : certains scripts contiennent des erreur s
de débutant : utilisation de scripts sans vérifier leur présence. J e
parle d'un problème récent qui avait une dépendance sur httpd et qu i
lançait /etc/init.d/apache dans le postinst. Forcément ca marche pas
avec apache2.
- 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.
- 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).
- 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 ;-).
- 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.
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).
- pas de scripts de tests automatiques.
- debconf : cette base des registres dont je n'ai toujours pas compris
l'utilité depuis 3 ans que je suis sous debian.
- qualité de certains paquets : certains scripts contiennent des erreur s
de débutant : utilisation de scripts sans vérifier leur présence. J e
parle d'un problème récent qui avait une dépendance sur httpd et qu i
lançait /etc/init.d/apache dans le postinst. Forcément ca marche pas
avec apache2.
- 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.
- 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).
- 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 ;-).
- 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.
