Re: Fréquence de mise à jour sid
Le 08/05/2013 20:06, Sylvain L. Sauvage a écrit :
> Le mercredi 8 mai 2013 à 19:14:19, Goldy a écrit :
>> […]
>> C'est bien pour ça que je pose la question. L'idée étant
>> justement de savoir lorsque les paquets passent de
>> experimental à unstable, s'ils le font de manière
>> relativement cohérentes ou non et si c'est le cas, si cela
>> est fait selon un planing prédéfinit ou de manière
>> anarchique.
>
> Les paquets ne passent pas de experimental à unstable.
>
> Contrairement à oldstable, stable, testing et unstable qui
> sont des distributions (= dépôt autosuffisant), experimental
> est juste un dépôt incomplet (comme backport) pour des paquets
> en test. Avant son existence, chaque DD qui voulait qu’on l’aide
> à tester ses paquets devait le mettre à disposition et
> l’annoncer comme il pouvait. Experimental sert juste à gérer ça
> plus proprement, simplement, efficacement et de façon plus
> ouverte (à d’autres testeurs).
>
> Les paquets qui arrivent dans unstable (pour descendre après
> dans testing), passent par la file NEW, accessible uniquement
> aux DD (ayant droit d’upload) et gérée par les ftp-masters.
>
> Donc, quand un paquet finit par plaire suffisamment à son DD,
> celui-ci l’envoie vers « incoming » et les responsables le
> mettent dans NEW (ou pas) et la charrette le ramasse au tour
> suivant (genre tâche cron) pour le mettre dans les dépôts.
Merci pour les précision. Je pensais effectivement que experimental
était un passage obligé pour les paquets, tout comme sid l'est pour
testing, etc.
D'ailleurs j'ai été également surpris de constater que sid était
également gelé tout comme l'est testing avant la sortie de stable.
>
>> À ce propos, je me demande si cela serait pertinent de
>> réaliser un dépôt alternatif à sid basés exclusivement sur
>> des scripts qui importerait les paquets en fonction de leur
>> ancienneté et de la satisfaction de leur dépendances. Je me
>> demande d'ailleurs si un tel script n'aurait pas déjà été
>> développé.
>
> Donc, en gros, une Testing sans le filtre « on attentd parce
> qu’il y a des bogues » ?
>
Grosso modo oui, si ce n'est qu'un temps de latence de quelques jours
permettrait à un bug existant d'être plus facilement reporté donc
facilement détectable avec apt-listbug et qu'il ne serait pas possible
de forcer ou enlever un paquet comme on peut le voir sur testing (c'est
ce qui m'a fait passer à sid personnellement), on peut également
imaginer de permettre la cohabitation de plusieurs versions d'un même
paquet (permettant de faire facilement un downgrade en cas de problème).
D'un point vu technique ça ne me semble pas très compliqué à
implémenter, c'est le genre de projet sur lequel j'aimerai volontiers
travailler, et même de mon point de vu, ce genre de fonctionnalités
auraient sans doute un intérêt à être présentes directement dans les
gestionnaires de paquets.
Reply to: