Re: entre stable et testing
* sferriol <sylvain.ferriol@imag.fr> [2003-08-27 13:49] :
> Roland Mas wrote:
> >sferriol (2003-08-27 10:40:43 +0200) :
> >
> >
> >>Question: faudrait il pas un niveau de release correspondant juste
> >>aux corrections de bugs????
> >
> >
> > C'est à ça que correspondent les mises à jour de stable (3.0r1 par
> >exemple). Seuls les gros gros bugs sont corrigés de la sorte,
> >cependant. Les bugs normaux ne sont pas corrigés pour stable, parce
> >que ça demanderait énormément de boulot (les bugs sont souvent
> >corrigés dans une nouvelle version amont, et rétroporter la correction
> >pour la version de stable serait pénible et gourmand en temps).
>
> la correction des bugs normaux pourrait rester dans un état testing et
> passer stable à chaque nouvelle distribution.
> Ainsi, il y aurait:
> - "stable" avec ses mises à jours correspondant aux gros gros bugs de
> sécurité.
> - "correction" avec les corrections des bugs normaux mais on reste dans
> un état de test.
> - "testing" avec les corrections + les nouvelles fonctionnalités.
Ça devient un boulot assez monstrueux pour un bénéfice qui ne parait pas
énorme AMHA. Et comment séparer simplement et dans tous les cas les
bogues normaux des nouvelles fonctionnalités ? Ce n'est probablement pas
si simple que cela.
> en fait j'essaie de voir comment mettre à jour ma distribution, car il y
> a des bugs qui me bloquent, sans tout passer au niveau testing.
Le rétro-portage de paquets bien précis devrait correspondre à ton attente.
> Par exemple, je suis obligé de mettre à jour debconf (car il y a un bug
> dans le driver LDAP) donc il faut que je charge debconf-1.3.8 de testing.
C'est un problème avec plusieurs paquets Debian : les développeurs
Debian font tellement de choses intéressantes qu'il est devient de plus
en plus difficile de rétro-porter des paquets vers stable (sauf cas très
particuliers). Après, tu peux essayer de "gruger" un peu les dépendances
de construction par exemple si elles semblent un peu trop fortes sans
raison valable. Ça demande du boulot et il n'est pas assuré que cela
fonctionne correctement ensuite.
> mais contrairement à la version 1.2.35, debconf dépend de debconf-i18n
> qui dépend de libtext-charwidth-perl (qui existe qu'en testing) qui
> dépend de perl-base >= 5.8.0-18, donc je suis obliger de passer perl en
> testing alors que le bug corrigé est minime et correspond à juste
> quelques lignes de code dans un fichier.
Dans ce cas, tu peux facilement créer des paquets Debian personnels
modifiés ne contenant que tes modifications, en faire une source APT
personnelle, tu peux également les proposer à d'autres personnes, mais
tu ne peux pas espérer que Debian les intègre actuellement dans la
distribution stable pour les raisons exposées ci-dessus.
Personnellement, c'est ce que j'ai fait pour quelques paquets qui
m'intéressent particulièrement comme gdb, dillo et quelques d'autres
(http://olympie.dyndns.org/debian/debs/ pour ceux que cela intéresse).
Par contre, il n'y a naturellement pas de suivi de sécurité sur ces
paquets (et je ne peux pas le garantir), ni même de garantie de
fonctionnement correct. Pas vraiment ce que l'on installerait sur une
machine stable de production ...
HTH
Fred
Reply to: