Re: forcer un buildd à re-construire
On Mon, Nov 12, 2001 at 08:31:18AM +0100, Raphael Hertzog wrote:
> Salut,
>
> Le Sun, Nov 11, 2001 at 11:16:36PM +0100, Ludovic Rousseau écrivait:
> > Le démon de reconstruction a fait deux essais le 7 novembre: un à 20h32
> > et un autre à 20h34. Les deux essais avec la même erreur "Can't find
> > source for ifd-gempc_0.5.5-1".
> >
> > Le paquet a été installé par Katie dans pool/ le 7 novembre à 20h25.
> > L'auto builder arm a été un peu trop rapide sur ce coup là ?
> >
> > C'est dommage puisque du coup le paquet risque de ne pas passer en
> > testing alors que c'est bon pour les autres architectures.
> >
> > Dans debian/control j'ai "Architecture: any" et pas "Architecture: all"
> > donc ça devrait quand même passer dans testing si j'ai bien compris.
>
> Ah non, cela n'a rien à voir. Architecture: all ca veut "indépendant de
> l'architecture" (genre code perl). Architecture: any ca veut dire que ca
> peut se compiler sur n'importe quelle architecture mais que les paquets
> ne sont pas "interchangeables" (ie un paquet compilé sur i386 ne
> marcherai que sur i386 et pas sur sparc ou ailleurs).
>
> Cela n'a *aucun* rapport avec l'algorithme de décision de testing. A la
> limite, un paquet architecture: all rentrera plus vite dans testing
> puisqu'il n'a pas besoin d'être recompilée. Attention, ce n'est pas une
> raison pour mettre Architecture: all sur un paquet qui ne fonctionne pas
> sur toutes les architecture...
Il me semble avoir lu des discussions comme quoi pour qu'un paquet avec
architecture: all entre dans testing, il faut que toutes les architectures
puissent entrer dans testing.
S'il n'y a pas de dépendances, tu as alors raison, mais s'il y en a,
le paquet risque d'être bloqué en dehors de testing parce qu'une des
dépendances n'est pas disponible dans la bonne version sur une des
architectures.
Ceci n'est qu'un vague souvenir de lectures de ML, corrigez-moi si je me
trompe.
Denis
Reply to: