Nouvelles hebdomadaires Debian - Courriel
- Debian 2.2 (surnommée Potato) [pas encore
publiée]
Le Gnome d'octobre est déjà inclus.
Assurez-vous simplement de sélectionner le profil « GNOME Workstation » lors de l'installation. - Debian 2.1 (surnommée Slink)
Procédure d'installation :
- assurez-vous que « apt » est installé sur votre système (vous pouvez le télécharger sur http://ftp.debian.org/debian/dists/stable/main/binary-i386/admin/apt_0.3.10slink11.deb) ;
- ajoutez la ligne
deb https://www.debian.org/~vincent/ slink-update main
dans votre fichier/etc/apt/sources.list
. Pour cela, tapez (en tant que superutilisateur) :echo "deb https://www.debian.org/~vincent/ slink-update main">> /etc/apt/sources.list
- téléchargez et installez les paquets
en utilisant apt ; tapez (en tant que superutilisateur) :
apt-get update apt-get install task-gnome-apps
Vous pouvez également utiliser la méthode apt de dselect : mettez à jour votre fichier sources.list puis faites une mise à jour dans dselect (et sélectionnez manuellement les paquets que vous voulez).
Vous pouvez également vouloir parcourir la liste complète des paquets et choisir d'installer individuellement des paquets supplémentaires en tapant (en tant que superutilisateur) :
apt-get install package-name (c'est-à-dire : apt-get install gnumeric)
Note : Le dépôt sera mis à jour de temps en temps pour inclure, le cas échéant, les nécessaires corrections de bogues. Ainsi, même après la mise à jour, nous vous encourageons à garder la ligne de ressource dans votre fichier sources.list, et à taper régulièrement apt-get dist-upgrade.
- Les versions de Debian avant la 2.1 ne sont pas gérées. Si vous voulez le Gnome d'octobre sur votre Debian 1.3 ou Debian 2.0, vous devez le recompiler à partir du source (soit en utilisant les archives tar amont, soit en utilisant les paquets de source de Debian).
À : debian-devel@lists.debian.org Sujet : Raisonnement d'Adam Di Carlo (était Re : GEL REPLANIFIÉ) De : Adam Di Carlo <adam@onshore.com> Date : 8 nov. 1999 21 h 26 ' 14 " -0500 Ci-jointe se trouve une justification du report du gel que j'ai envoyée au forum slashdot. C'est la première fois que j'ai posté à cet endroit, mais j'ai très peur de devenir la personne la plus détestée de Debian. Dans tous les cas, je la poste ici au cas où des personnes veulent la lire. Veuillez juste me laisser faire une préface en disant que je suis d'accord avec ceux qui disent qu'un gel reporté de deux mois avec un cycle d'un mois (si nous le réussissons) est mieux qu'un gel de trois mois. Pour les développeurs ici, j'espère que vous éviterez d'envoyer des paquets très instables tant que Potato n'est pas publiée. -- .....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/> Tous ceux qui observent Debian depuis plus d'un an savent que la période de gel est une phase très importante du projet. Le gestionnaire de publication, Richard Braakman, a déclaré son désir que la durée totale du gel ne soit pas plus longue que trois ou quatre semaines. La discussion que j'ai eue avec lui concernant l'état de préparation des disquettes de démarrage, en particulier, n'était que pour s'assurer qu'il a toutes les informations nécessaires pour faire de son rêve une réalité. Toute la question est d'entrer dans le gel avec un système d'installation composé de toutes les fonctionnalités et prêt en version bêta. Sans cela, ce n'est pas possible. Pour ceux qui se souviennent du gel de Slink, il y a eu un cycle d'environ 16 semaines (elle a été gelée au milieu de novembre, avec une publication à la mi-mars), qui a été plutôt stressant pour tout le monde. Notre objectif est que le gel soit prévu sur un ensemble assez stable de paquets, ce qui nous permet complètement de tester plus sainement l'installation à partir de rien ainsi que les mises à niveau de Slink vers Potato [Pour votre information, mon estimation actuelle est que nous aurons des disquettes de démarrage complètes le premier décembre. Je peux l'affirmer avec la conviction que le premier janvier 2000, nous aurons ce que j'appelle des disquettes de démarrage « de qualité pour la publication » (c'est-à-dire ayant été beaucoup testées, mais avec encore un peu de documentation à faire).] Laissez-moi juste aborder quelques autres points rapidement. * La raison principale pour laquelle je veux plus de temps pour les fonctionnalités des disquettes de démarrage est que je pense qu'elles sont très importantes. Parcourons-les brièvement : un nouveau mécanisme de sélection du profil et des métapaquets task, qui permet de continuer à utiliser ces mécanismes même après l'installation ; utilisation d'apt dans quasiment tous les cas [pour la récupération des paquets ; oui, je sais qu'il y a des situations avec des serveurs mandataires SOCKS et d'autres situations obscures où cela peut ne pas être une réalité] ; un configurateur d'apt, avec la possibilité de détecter automatiquement les CD officiels aux endroits attendus ; la possibilité d'installer base2_2.tgz via http et peut-être ftp ; ensemble des données réseaux pour bootp et dhcp lorsque c'est disponible ; superviseur de l'installation du paquet X, capable de détecter automatiquement le paquet correct du serveur X. Je pense que ces avancées sont importantes. Même avec le report, j'espère que nous aurons le temps de les implémenter. * Ceux qui disent que nous ne gèlerons jamais racontent des bêtises. Nous désirons fortement nous mettre à jour et rendre obsolète la distribution Slink. * En ce qui concerne Linux 2.4, non, nous n'envisageons pas de synchroniser nos cycles de publications avec ceux de Linux, ce qui devrait être clair pour tout le monde. Pour le meilleur ou pour le pire. En supposant que Linux 2.4 est stable (2.2 n'était pas si bien que ça au niveau de la stabilité lorsqu'il est sorti, AMHA) et sortent dans les prochaines semaines, il est certain que je ne m'y lancerai pas. Actuellement, nous pensons utiliser 2.2.13 (même si cela peut varier entre nos 5 architectures différentes). * Nous réalisons que les mécanismes actuels de gestion des publications montrent les limites dues à l'élargissement du projet. Il y a deux approches possibles pour ce problème : (a) faire plus de « publications intermédiaires » du système stable, ce qui nécessite simplement une équipe plus importante qu'actuellement pour s'occuper de la distribution stable après sa publication ; (b) reconcevoir complètement la gestion des publications, le candidat le plus probable pour cela étant la proposition de « dépôts de paquets » -- je n'ai pas de lien sous la main. * Même avec cela, je voudrais le répéter, Debian reste la seule distribution ayant un système de mise à niveau robuste et mis à l'épreuve (que ce soit pour les nouvelles publications, récupérer des paquets de la distribution instable, ou quoi que ce soit d'autre). * Tant que nous sommes dans le domaine des « excuses », je ne pense pas que beaucoup réalisent ici la quantité d'efforts nécessaires pour coordonner Debian en général (ou les disquettes de démarrage, pour ce qui nous concerne). Ce travail se réalise en coulisse, et certains d'entre vous interprètent la lenteur de résolution de cette question comme de l'indifférence. Je peux vous assurer que nous ne sommes pas indifférents, en particulier en ce qui concerne la fréquence des publications et la qualité des disquettes de démarrage.
Date : Mar. 9 nov. 1999 07 h 23 ' 23 " +1100 De : Chris Leishman <masklin@debian.org> À : debian-devel@lists.debian.org Sujet : Gel partiel ? OK, Voici une autre réflexion (sûrement une qui est déjà ressortie - nous aimons tourner en rond. Faites-le moi savoir si c'est le cas). Le problème pour le moment est que personne ne veut du gel, car nous ne savons pas combien de temps il va durer - et pendant ce temps, les choses sont bloquées et vieillissent. Et pourquoi ne savons-nous pas combien de temps nous allons geler ? Car quelques paquets « critiques à publier » (comme les disquettes de démarrage) ne sont pas stables et nous ne savons pas combien de temps il faudra avant qu'ils ne le soient. Cependant - AMHA si nous ne gelons pas, alors nous sommes dans la même situation que la distribution instable - à tout moment il peut y avoir une mise à jour qui va provoquer l'échec d'un nouveau paquet « critique à publier ». Qui sait - dans un mois quand nous aurons des disquettes de démarrage, des paquets neufs ou mis à jour (ou une nouvelle charte) pourraient nous empêcher de geler pour les mêmes raisons... C'est vraiment un casse-tête. Si nous gelons, alors les choses vont se stabiliser, mais elles risquent de périmer. Si nous ne gelons pas, les choses ne périmeront pas, mais elles risquent de ne pas se stabiliser rapidement. Que faire alors : Nous identifions les paquets qui sont considérés comme « critiques à publier ». Cela inclurait les paquets comme les disquettes de démarrage et la charte. Ensuite nous déclarons un _gel de ces paquets_. Les mêmes règles que pour un gel normal s'appliquent - seules les corrections de bogues sont permises pour ces paquets. Cependant, les nouveaux envois peuvent continuer pendant que cette chose se stabilise - tant qu'ils ne créent pas de problème avec les paquets « critiques à publier ». S'ils en créent, alors les règles du gel s'appliquent sur cet envoi (pas de nouveau code). Nous gèlerons éventuellement la distribution complète pendant un court moment, pour nettoyer les bogues dans les paquets non principaux. Nous devrions nous imposer une discipline stricte pour cela, et globalement dire que s'il y avait une version sans _nouveau code_ qui n'a pas montré de problème, alors nous la gardons plutôt que de corriger des bogues. OK... la conclusion de cette idée.... Cela _peut_ allonger la période de gel, puisque nous en faisons en pratique 2. Mais la deuxième phase (la phase qui peut introduire une stagnation) sera bien plus courte qu'elle ne l'est dans notre situation actuelle. Une autre conclusion serait que cela semble être une évidence, et il n'y a pas besoin de le rendre officiel... mais j'ai toujours trouvé que ces choses fonctionnent mieux quand elles sont obligatoires. La dernière question restante est la faisabilité de ce concept... Cordialement, Chris (Souhaitez-moi bonne chance pour mon examen de macroéconomie dans... oh !... une heure et demie :)) -- ---------------------------------------------------------------------- Linux, car j'aimerais *y être* aujourd'hui ---------------------------------------------------------------------- Répondez avec le sujet « request key » pour la clé GPG publique. Identifiant de clé : 0xB4E24219
À : debian-devel-announce@lists.debian.org Cc : ftpmaster@debian.org Répondre-à : ftpmaster@debian.org Sujet : Nouveaux membre de l'équipe de maintenance de l'archive De : James Troup <james@nocrew.org> Date : 9 nov. 1999 00 h 41 ' 51 " +0000 [ Veuillez ne pas répondre à debian-devel-announce ] Salut, J'aimerais souhaiter publiquement la bienvenue à Gergely Madarasz et Antti-Juhani Kaijanaho qui rejoignent Guy, Richard et moi en tant que membres de l'équipe de maintenance de l'archive. Même si nous n'avons initialement demandé qu'une seule personne pour aider, nous avons décidé de prendre deux nouveaux membres en raison du nombre de nouveaux paquets qui sont envoyés tous les jours. Merci à tous ceux qui se sont gentiment portés volontaires pour aider. - -- James
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.