Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Mon, Jun 23, 2003 at 09:23:38AM +0200, Georges Mariano wrote:
> On Mon, 23 Jun 2003 01:55:37 +0200
> Laurent Defours <laurent.defours@laposte.net> wrote:
>
> > Le lundi 23 juin 2003, à 01:11, Georges Mariano écrivait :
> > > Crois moi sur parole ;-)
> >
> > Non. (et je suis pas DD)
>
> ça change tout... ;-)
>
> alors voilà (c'est long...):
>
> Ça se passe en (plutôt) oldstable [je suis en potato, woody vient de
> sortir]
>
> Je souhaite installer le paquet A.v1.
> J'installe, je lance le programme correspondant A, et boum ça plante.
> C'est du perl, j'ai un message sur le fichier fB, qui appartient au
> paquet B (que j'ai en version mettons v1...)
Pourquoi ne pas utiliser les vrais nom de packages ? Il s'agit
probablement d'un cas pathologique, que tu generalise un peu facilement
ici.
> Pourtant, je vais voir dans le paquet les dépendances sont
> satisfaites... A depends de B-v1.
>
> Alors ? Juste pour voir, apt-get install B -t sarge
> Je récupère la B-v2
> Je relance A, ça marche!!
>
> Utilisateur docile : bugreport, Cher DD adoré, faut mettre une
> dépendance sur B.v2 et non pas B.v1. Voilà... On est content.
>
> C'est tout ? Non. Que s'est-il passé ? Proposition de scénario.
Le probleme est une mauvaise manip du cote du DD en question, je suis
sur que le probleme n'apparait pas sur d'autres arches, qui sont
auto-built. Moi lorsque je prepare un upload a stable-proposed-updates,
je le construit dans un pbuilder bien sur, ou sur une machine stable de
debian, et le probleme ne se pose pas.
> Le DD a fait une 1ère version, il y a un certain temps avec une
> dépendance sur B.v1 (pour x raisons, ça marchait). Ensuite, comme tout
> DD qui se respecte, il suit la meute et upgrade régulièrement ça
> machine, tout évolue (paquet A et paquet B). Nouvelle version du paquet
> A construite dans le contexte sid "comme il se doit" mais avec B-v2
> maintenant. Petit test de A. ok, ça marche. Paquet dans sid, personne ne
> voit rien tout les lemmings de cet acabit sont en sid ... ça arrive dans
> testing... j'installe chez moi et boum, ça plante. Durée du test : 2mn.
Erreur, cela ne peut pas arriver dans testing sans que B-v2 y arrive
aussi, car c'est comme cela que marche les testing script, meme pire, il
ne peut pas mettre de nouveaux packages en testing si ils cassent quoi
que ce soit en testing.
> J'ai une furieuse envie de laisser les DDs finir l'explication ;-)
>
> Explication : toutes les dépendance ne sont pas calculées
> automatiquement, en particulier ... ?? Celles pour les paquets qui
> dépendent d'un interpréteur. En effet, les dépendances automatiques sont
Et alors, ils ne sont certe pas calcule automatiquement, mais cela c'est
le probleme du packageur et du packageur de l'interpreteur, qui devrait
resoudre cela a la main, ou alors trouver une solution.
Comme exemple, les packages ocaml bytecode dependent de la version de
ocaml-base avec laquelle ils ont ete compiler. Donc ils ne peuvent pas
simplement dependre de ocaml-base, mais doivent dependre soit de
ocaml-base (>= v), ocaml-base (<< v+1) ou alors de ocaml-base-v comme
c'est le cas maintenant. Mais je me rappelle que tu a raler tres fort
lorsqu'on a fait cela, parceque tu avait du mal a backporter les
packages en question.
> calculées à partir des liens de liaisons binaires<->librairies, donc
> dans le cas de paquets perl/python/... par exemple... ben ça coince.
> Faut faire évoluer à la main... et c'est d'autant plus difficile que
> l'organisation (découpage en paquet) évolue.
>
> Chacun est libre d'utiliser woody ou sarge ou sid mais pour faire un
> paquet, il vaut mieux se replacer dans le contexte stable pour détecter
> les dépendances "minimales" (c'est à dire plutôt celles qui sont en
> cours chez les utilisateurs... concept bien trop subtil pour un DD/sid
> j'en conviens).
N'importe quoi. Aucun package ne sera jamais ajouter a stable, donc il
n'y a aucun interet a faire de nouveau paquet pour stable. De la meme
maniere, il est extremement rare qu'une nouvelle version d'un paquet
soit ajouter a stable, donc pourquoi faire ce que tu propose ?
Meme lorsque j'ai preparer le package ocaml 3.04-14 pour woody 3.0r1
(woody avait 3.04-12 qui avait, pas un bug, mais un probleme dans la
migration vers 3.06-x), j'ai compiler les packages dans un pbuilder,
puis je suis aller les construire a la main dans chacune des
architecture qui n'avait pas d'autobuilders pour
stable-proposed-updates, et j'ai fait l'upload. Comme tu le vois, je
prend des precautions plus grande que les gens qui font des backport un
peu bacle, et c'est normal que cela risque de poser des problemes par la
suite.
> Pourquoi je détecte le bug grossier en 2mn et pas le DD ? Parce que je
> suis en stable et lui en sid...
Parceque tu essaye de faire tourner en woody un package prevu pour sid,
c'est tout.
> => un DD devrait travailler dans un chroot qu'il fait évoluer en
> fonction des paquets qu'il construit (et teste) et rien de plus. Cela
> permettra que _ses_ dépendances (manuelles) soient spécifiées au plus
> juste. Ça sera déjà un paquet de bug en moins.
A nouveau, un DD travaille pour la prochaine release de stable, stable
est par definition stable, ce qui veut dire que pas un nouveau package
ne viendra s'y ajouter, ni qu'une nouvelle version d'ailleurs. La
security team s'occupe de toute mise a jour de stable en faissant des
backport des problemes de securite ou d'autre bugs serieux, et les
mainteneurs peuvent des fois aussi faire de tels backport, mais avec
precaution et attention, et pas en faissant juste un apt-get source -b
<package> comme l'espere faire la pluspart des backporteurs. C'est cela
le prix a payer pour que debian soit considerer comme la distrib la plus
stable, et bien sur, si tu veut faire une distrib de qualite de
backport, rien ne t'en empeche, comme dis de nombreuse personnes s'en
rejouiront et meme t'aideront a le faire. Ceci dis, debian ne peut pas
se permettre de faire cela actuellement sans hypothequer la prochaine
version stable, et cela nous ne le desirons pas.
Personnellement, je crois qu'il est plus important de releaser plus
souvent que de faire des backport a la qualite douteuse, mais bon, je
suis sur que tu ne partage pas mon avis.
> Mais je crois pas que le problème soit technique, en fait. Le DD doit
> être en général quelqu'un de très technique (on dit péjorativement
> bidouilleur). À l'aise uniquement dans le dernier cri, le passé pour lui
> est obsolète. Ce qui lui faut c'est du sid. Bah, ça se comprend.
> Sincèrement.
Rien a voir, c'est juste que tu utilise un produit (le package unstable)
dans un environement pour lequel il n'est pas prevu (la distrib stable),
et qui plus est, pour laquelle on previent qu'il n'est pas prevu, c'est
a tes risques et perils donc.
> Par contre, construire dans stable, bof, mouai, ça manque d'adrénaline.
> Sauf que c'est le plus stable. Et c'est là l'essentiel de ma critique,
> on ne dit pas que l'on mets les besoins utilisateurs et la stabilité de
> la distrib sont prioritaires (et toutes les distributions disent la même
> chose ;-) quand on demande aux DD de bosser dans sid.
On voit bien que tu n'a pas compris ce que veut dire stable, ou alors
que tu choisi de l'ignorer pour pouvoir pousser ton argument. Il n'y a
pas pire sourd que celui qui ne veut pas entendre.
> Ça, c'est une arnaque. On confond utilisateurs et mainteneurs.
Pourquoi ? Le contrat de debian avec ces utilisateurs, c'est de leur
donner une distribution stable. une fois cela fait, la security team et
un certains nombre de developpeurs debian s'occupe de la maintenance de
stable, pendant que le reste des developpeurs s'attaquent a la
realisation de la version suivante. C'est ce qu'on fait, cela marche
bien, et si tu veut plus, libre a toi de le faire.
C'est comme quand tu achete une voiture, tu achete le modele present au
moment de l'achat, mais tu n'a pas automatiquement les nouvelles options
qui viennent s'y ajouter au fur et a mesure que le modele evolue. Et
encore, une voiture, tu paye pour, alors que debian, c'est gratuit et
libre.
Amicalement,
Sven Luther
Reply to: