Re: Conseils pour un dépôt Debian interne
Le Thu, 5 Apr 2012 17:36:36 +0200,
Bzzz <lazyvirus@gmx.com> a écrit :
>On Thu, 5 Apr 2012 15:35:15 +0200
>David BERCOT <debian@bercot.org> wrote:
>J'ai un faible pour debmirror (voire ftpmirror): facile à
>configurer et à lancer 1/24 par un cron.
Bon, il faut que je regarde comment il fonctionne...
>> A priori, j'ai prévu deux branches, l'une, stable (pas besoin de
>> développer) et l'autre, testing, qui servira à valider de
>> nouveaux paquets avant de les mettre dans stable.
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>Heu, on parle bien d'un repo pour les SERVEURS là, hein?
Tout à fait. Mais ce que j'appelle "testing", ce n'est pas Debian
Testing mais une zone de validation de notre côté avant la mise à
disposition pour les serveurs...
Quand il y a des mises à jour, même sur le repository "stable", il faut
d'abord qu'on valide que ça n'a aucun impact sur nos applis.
De ton côté, sur les serveurs, tu fais directement les mises à jour
fournies par Debian ? Sans validation préalable ?
>> Maintenant, je me demande comment alimenter au mieux ces deux
>> branches car plusieurs outils sont disponibles comme reprepro
>> ou apt-mirror, voire de façon "manuelle". Il y a aussi les
>> aspects "sécurité" et "backports" par exemple...
> ^^^^^^^^^^^
>Bis Repetita.
>
>securité & backports sont mutuellement exclusifs dans le sens où
>backports a 99% de chances de contenir des trous de sécu &| des
>bugs.
Difficile de faire sans backports pour certains besoins, PostgreSQL 9
par exemple...
>> Enfin, quand la version stable évolue (changement de version
>> majeure par exemple), comme gérer tout ça au mieux.
>
>Facile: n'importer les branches que par leurs petits noms, puis
>créer les symlinks voulus (stable & testing).
>
>Je ne vois pas ce que du testing viendrait faire sur des serveurs
>en prod...
Parce que ce n'est pas du vrai "testing" ;-)
David.
Reply to: