Nouvelles hebdomadaires Debian - Courriel

À : Raphaël Hertzog <rhertzog@hrnet.fr>
Cc : Zephaniah E. Hull <warp@whitestar.soark.net>,
  debian-perl@lists.debian.org
Sujet : Re : Plans de publication (10 mai 1999)
Répondre-à : torin@daft.com
De : Darren Stalder <darren@u.washington.edu>
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'application compilée 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 seule 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 tous à 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 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.

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 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
- --
<torin@daft.com> <http://www.daft.com/~torin> <torin@debian.org> <torin@io.com>
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.	      @

Date : Lun. 17 mai 1999 22 h 14 ' 50 " +0200
De : Stefan Gybas <cab@studbox.uni-stuttgart.de>
À : 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 debian-admintool@lists.debian.org.

--
Stefan Gybas

1. Qu'est-ce que Linuxconf ?

   Linuxconf est un programme pour les systèmes Linux avec trois fonctions
   majeures :

   (a) Utilitaire de configuration

       Avec Linuxconf, vous pouvez faire de l'administration et de la
       configuration système basique et avancée. Linuxconf possède quelques
       fonctionnalités de base (comme créer et gérer les utilisateurs,
       les groupes et les systèmes de fichiers) et quelques autres modules
       pour d'autres composants systèmes, par exemple bind, apache, sendmail,
       samba et squid. Actuellement, il y a plus de 20 modules disponibles.

       La configuration est faite au travers d'une interface graphique
       contenant beaucoup de texte d'aide, qui peut être visualisé avec une
       interface textuelle, graphique ou web.

       Linuxconf n'utilise pas de base de données pour enregistrer la
       configuration. À la place, il utilise les fichiers normaux de
       configuration du système, comme /etc/fstab, /etc/hosts - tout en
       essayant fortement de conserver la structure (comme les commentaires
       ajoutés manuellement). Donc vous pouvez toujours choisir entre un
       éditeur texte et Linuxconf.
   
   (b) Activateur et gestionnaire de configuration

       Linuxconf peut garder la trace des changements faits aux fichiers
       de configuration (en utilisant Linuxconf ou un éditeur texte) puis
       mettre à jour le système pour refléter ces changements. Un exemple
       peut être :

       vi /etc/inetd.conf
       vi /etc/apache/httpd.conf
       linuxconf --update         # Cela provoquera le rechargement des
                                  # fichiers de configuration d'inetd et
				  # d'apache

       Une autre fonctionnalité est la possibilité d'archiver et de
       récupérer les fichiers de configuration (en utilisant RCS si
       disponible) :

       linuxconf --archive
       linuxconf --diff
       linuxconf --extract
       
   (c) Sélectionneur de démarrage

       La troisième fonctionnalité principale de Linuxconf est appelée
       askrunlevel et c'est exactement ce que cela fait. Il montre un petit
       menu au démarrage où vous pouvez sélectionner le niveau de lancement
       du système et le profil.

       Un profil est le nom d'une configuration archivée (en utilisant la
       section b) comme « bureau » ou « maison », donc, par exemple, vous
       pouvez avoir des adresses IP ou des configurations de XFree
       différentes sur votre ordinateur portable en fonction de votre
       emplacement.

   Chacune de ces fonctionnalités peut être activée ou arrêtée indépendamment,
   ce qui signifie que vous n'avez pas besoin d'activer le sélectionneur
   de démarrage si vous voulez seulement faire la configuration de Samba.
   Et vous pouvez toujours désinstaller le paquet Linuxconf et tout redevient
   comme avant.


2. Où puis-je obtenir le paquet Debian Linuxconf ?

   J'ai divisé Linuxconf en quatre paquets Debian séparés :

   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
                     paquet séparé de manière à ce que le paquet principal
		     ne dépende pas de xlib6g, wxxt1 et xpm4g).

   linuxconf-locale  Les fichiers d'internationalisation (tout sauf l'anglais).

   linuxconf-boot    Le sélectionneur de démarrage (voyez la section 1c) - si
                     vous ne voulez pas activer cette fonctionnalité,
		     n'installez tout simplement pas ce paquet et Linuxconf
		     ne fera aucune modification importante à votre système.

   Tous les paquets sont dans la distribution « experimental » disponible
   sur tous les miroirs de Debian dans project/experimental/. Ils peuvent
   être installés sur un système Debian 2.1 (Slink) mais nécessitent
   un paquet netbase plus récent.


3. Qu'est-ce qui fonctionne sur Debian GNU/Linux ? Et qu'est-ce qui ne
   fonctionne pas ?

   Tout ce qui concerne la configuration (voyez 1a) à l'exception de la
   configuration du réseau fonctionne sur Debian. L'activateur de
   configuration (1b) et le sélectionneur de démarrage (1c) fonctionnent
   partiellement (voyez la question 4).


4. Que faut-il faire pour activer les autres fonctionnalités ?

   Le problème avec la configuration du réseau est que cela se fait
   différemment sur chaque distribution Linux, donc Linuxconf ne sait pas
   où enregistrer le nom d'hôte, les adresses IP et la table de routage.
   C'est pourquoi des modules spécifiques aux distributions ont été écrits,
   mais malheureusement il n'y en a pas encore de disponible pour Debian.

   Pour l'activateur de configuration, Linuxconf doit savoir quel fichier
   de configuration appartient à quel service/démon et comment faire
   pour que le démon recharge sa configuration. Encore une fois, c'est
   spécifique aux distributions, mais Linuxconf a quelques connaissances
   basiques, par exemple, il sait que inetd utilise /etc/inetd.conf et
   peut être redémarré en utilisant « kill -HUP ».

   Mais comme vous le savez probablement, Debian utilise les scripts
   d'initialisation SysV dans /etc/init.d/ qui peuvent forcer un démon à
   recharger sa configuration, comme dans « /etc/init.d/proftpd reload ».
   Ainsi, cela serait une bonne idée de dire à Linuxconf quel script
   d'initialisation lance quel(s) démon(s) et quel(s) fichier(s) de
   configuration il(s) utilise(nt). Cela est fait en utilisant des marques
   spéciales dans ces scripts d'initialisation. Veuillez lire
   http://www.solucorp.qc.ca/linuxconf/tech/sysvenh/index.html pour plus
   de détails.

   Dans les versions récentes de Linuxconf, ces « marques des scripts
   d'initialisation » peuvent également être enregistrées dans des fichiers
   différents, donc ils ne doivent pas être enregistrés dans les scripts
   d'initialisation fournis par les responsables de paquet, même si
   cette solution permettrait plus de consistance (et c'est la manière
   dont c'est fait dans Red Hat).

   Pour résumer ce qu'il faut faire :

   (a) Créer les marques nécessaires pour tous les scripts d'initialisation
       possible, pour que Linuxconf puisse utiliser ces scripts pour recharger
       une configuration, plutôt que d'utiliser ses propres règles.
       Peut-être que plus tard, ces marques pourront être ajoutées à
       l'intérieur de ces scripts d'initialisation si cela devenait une
       règle.

   (b) Écrire un module Debian pour gérer la configuration du réseau. Ce
       module aurait à lire l'actuelle configuration réseau dans
       /etc/init.d/network et enregistrer les changements dans ce fichier.
       Malheureusement, ce fichier est actuellement difficile à parcourir
       (comme c'est un script shell qui peut utiliser des variables
       et des commandes sans ordre particulier), donc ce module
       serait très compliqué si vous voulez conserver la structure de
       ce fichier.

       Une proposition a été faite sur debian-devel pour passer à un
       schéma différent de configuration réseau utilisant des fichiers
       faciles à parcourir (voyez par exemple
       https://lists.debian.org/debian-devel-9902/msg01420.html).
       Je pense que la seule façon pour Linuxconf (et tout autre outil de
       configuration) de gérer la configuration du réseau sur Debian est
       d'utiliser ce nouveau schéma ou celui de Red Hat, donc nous pourrions
       utiliser tout simplement des parties du module Red Hat de Linuxconf.


5. Quels sont les prochains objectifs pour le paquet Linuxconf ?

   J'ai l'intention d'envoyer l'une de mes prochaines publications dans
   la distribution instable (Potato) au lieu de l'expérimentale. Je ne
   vais pas inclure le paquet linuxconf-boot (qui fournit le sélectionneur
   de démarrage - voyez 1c) dans cet envoi, puisque cela peut causer des
   problèmes en raison de la configuration réseau qui ne fonctionne pas.
   Il n'est également pas très utile dans Debian car les niveaux de
   démarrage de 2 à 5 sont tous égaux et la configuration du réseau
   est faite au niveau S, donc Linuxconf n'a pas de solution pour désactiver
   la configuration du réseau si l'utilisateur choisit cette option
   dans askrunlevel.

   Le module Red Hat gère le PAM, donc vous pouvez par exemple changer
   le mot de passe d'un utilisateur en l'utilisant. Je vais copier cette
   partie dans un module Debian que j'espère créer bientôt.

   Mais la première étape serait de créer des fichiers avec les marques
   pour les scripts d'initialisation SysV (voyez la question 4) - cela
   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, 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é.

   La prochaine étape serait de faire fonctionner la configuration du
   réseau, mais comme cela a été expliqué dans la question 4 ci-dessus,
   Debian devra d'abord adopter un nouveau /etc/init.d/network.

Pour recevoir cette gazette chaque semaine dans votre boîte à lettres, abonnez-vous à la liste de diffusion debian-news pour la version anglaise ou à la liste de diffusion debian-news-french pour la version française.

Les dernières parutions de cette gazette sont disponibles.

Ce numéro de la Debian Weekly News a été édité par Joey Hess.
Il a été traduit par Thomas Huriaux.