Bonjour,
voici une relecture,
cordialement
Bernard Gisbert
Thomas Huriaux a écrit :
Merci d'avance pour vos relectures.
------------------------------------------------------------------------
#use wml::debian::weeklynews::header PAGENAME="Courriel"
#use wml::debian::translation-check translation="1.5" maintainer="Thomas
Huriaux"
<a name=1></a>
<pre>
À : Raphaël Hertzog <[EMAIL PROTECTED]>
Cc : Zephaniah E. Hull <[EMAIL PROTECTED]>,
debian-perl@lists.debian.org
Sujet : Re : Plans de publication (10 mai 1999)
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL
PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Répondre-à : [EMAIL PROTECTED]
De : Darren Stalder <[EMAIL PROTECTED]>
Date : 14 mai 1999 15 h 44 ' 54 " -0700
Raphaël Hertzog, dans une manifestation immanente de perspicacité, a écrit :
> Nous devrions faire pareil pour perl : tous les modules doivent
> utiliser la dernière version de perl, mais peuvent fournir des perl
> plus anciens pour les personnes qui en ont besoin (mais il n'y a pas
> de raison de leur fournir des modules, de la même manière que nous ne
> fournissons pas d'applications compilées avec libc5).
> perl5.005 devrait être le perl officiel de Debian, mais perl5.004
> devrait toujours être fourni pour aider les développeurs perl.
> Cela est vrai s'ils font une mise à niveau partielle. Mais pouvez-vous
> m'expliquer comment vous comptez résoudre ce problème ? Et pas
> seulement pour Potato en disant simplement que ce ne sera pas un
> problème puisque perl5.004 sera utilisé ! Comment allez-vous le gérer
> au moment où nous passerons à perl5.005 ?
> La <strong>seule</strong> façon de gérer complètement les mises à niveau
partielles
> serait de :
>
> - reconstruire tous les modules avec le nouveau perl5.004 (donc en
> ayant une dépendance avec perl5.004) ;
> - attendre que les gens les utilisent et les mettent <strong>tous</strong>
à niveau
> (et vous ne pouvez pas en être certain car ils peuvent très bien faire
> des mises à niveau partielles !) ;
> - installer perl5.005 et reconstruire tous les modules pour perl5.005
> avec les dépendances appropriées.
Il y a un meilleur plan pour cela. Un paquet perl vide qui dépend de
perl-5.004 est envoyé. Quand quelqu'un met à niveau Perl, cela installe
automatiquement perl-5.004. Le paquet perl-5.004 fournit perl et perl5.
Cela signifie que l'ancien paquet perl peut être retiré. Ainsi, nous
avons une variété de modules qui dépendent de perl. Nous envoyons
un paquet perl-5.005. Il fournit perl5 mais est en conflit avec perl.
Pour que quelqu'un installe ce paquet (sans utiliser --force), il doit
mettre à niveau tous ses modules qui dépendent de l'ancien paquet perl.
Tous les nouveaux modules dépendront de perl5.
Ainsi, nous avons des Perl versionnés qui peuvent être mis à niveau
partiellement sans problème (je suppose).
Les paquets peuvent toujours dépendre d'une version particulière de
perl-5.* s'il le faut. La dernière version de Perl sera la version
préférée par défaut avec update-alternatives. Cela rend mes scripts
base.{postinst,prerm} bien plus simple. Ainsi, si à la fois perl-5.004 et
perl-5.005 sont installés, /usr/bin/perl référera à 5.005 si l'utilisateur
ne change rien. Quand perl-5.006 sera publié, il y aura eu un précédent.
Raphaël Hertzog, dans une manifestation immanente de perspicacité, a écrit :
> Donc, Darren, qu'en penses-tu ? La conclusion finale que j'ai tirée est
> que :
> - nous devrions avoir un répertoire commun pour les modules non binaires.
> Je ne sais pas si cela devrait être /usr/lib/perl5 ou un de ses
> sous-répertoires ;
Cela peut être /usr/lib/perl5 pour tous les modules Perl non binaires
qui ne viennent pas avec le paquet Perl. Tous les modules qui viennent
avec perl-5.\d+ iront toujours dans des répertoires versionnés.
Je ne vois pas de raison pour que cela soit autre chose que /usr/lib/perl5.
> - nous devrions toujours gérer le dernier perl, tout en laissant un
> un ancien disponible pour les développeurs. Tous les modules devraient
> être compilés avec le dernier perl. Si pour une raison ou pour une
> autre il y a besoin d'un module pour un ancien perl, nous devrions
> le nommer libmodule-perl-<ancienne_version_de_perl>. Cette
> situation peut uniquement se produire pour des modules binaires,
> puisque les modules non binaires partagent un répertoire non
> versionné commun à tous les perl.
Je suis d'accord avec cela...
> Si le répertoire commun dont on parle n'est pas /usr/lib/perl5, alors
> nous en aurons toujours besoin dans @INC pour perl5.005 dans Potato.
Actuellement, il ne le faudrait que dans perl-5.004 en raison de la
méthode que j'ai mentionnée ci-dessus.
Darren
- --
<[EMAIL PROTECTED]> <http://www.daft.com/~torin> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996
@ Administrateur système, créateur de sites web, postmaster à louer. @
Programmateur/enseignant C/Perl/CGI/Pilot @
@ Mettez un peu de chaleur dans votre esprit. @
</pre>
<hr>
<a name=2></a>
<pre>
Date : Lun. 17 mai 1999 22 h 14 ' 50 " +0200
De : Stefan Gybas <[EMAIL PROTECTED]>
À : linuxconf@xc.org, debian-devel@lists.debian.org,
debian-admintool@lists.debian.org
Sujet : FAQ et appel à l'aide : Linuxconf et Debian
Salut !
Je reçois plein de courriels remplis de questions sur mon paquet Debian
Linuxconf, donc je les ai rassemblées dans une petite FAQ (attachée).
Je désire également continuer à intégrer Linuxconf dans Debian mais
cela demande beaucoup de travail. Si vous voulez m'aider, veuillez me
contacter.
Si vous voulez répondre à ce courriel, veuillez choisir la liste de
diffusion appropriée. Pour les questions générales à propos de Linuxconf,
utilisez linuxconf@xc.org, pour les questions spécifiques à Debian,
utilisez [EMAIL PROTECTED]
--- mail.wml 2005-05-29 13:50:02.008768976 +0200
+++ mail.wml.relu 2005-05-29 14:14:16.274686952 +0200
@@ -55,7 +55,7 @@
Les paquets peuvent toujours dépendre d'une version particulière de
perl-5.* s'il le faut. La dernière version de Perl sera la version
préférée par défaut avec update-alternatives. Cela rend mes scripts
-base.{postinst,prerm} bien plus simple. Ainsi, si à la fois perl-5.004 et
+base.{postinst,prerm} bien plus simples. Ainsi, si à la fois perl-5.004 et
perl-5.005 sont installés, /usr/bin/perl référera à 5.005 si l'utilisateur
ne change rien. Quand perl-5.006 sera publié, il y aura eu un précédent.
@@ -195,7 +195,7 @@
J'ai divisé Linuxconf en quatre paquets Debian séparés :
- linuxconf Le binaire principale de Linuxconf (interfaces texte
+ linuxconf Le binaire principal de Linuxconf (interfaces texte
et web seulement, avec tous les modules).
linuxconf-x L'interface graphique pour Linuxconf (c'est dans un
@@ -306,7 +306,7 @@
peut être fait pas à pas. Une fois que nous aurons des marques pour la
plupart des scripts, nous pourrons dire à Linuxconf d'oublier ses
propres règles et de n'utiliser que les informations contenues dans les
- marques. Je recherche de l'aide, dons si vous désirez aider, veuillez
+ marques. Je recherche de l'aide, donc si vous désirez aider, veuillez
lire http://www.solucorp.qc.ca/linuxconf/tech/index.html (et en particulier
http://www.solucorp.qc.ca/linuxconf/tech/sysvenh/index.html) puis
m'envoyer un courriel si vous êtes toujours intéressé.
