* [gentoo-commits] gentoo commit in xml/htdocs/proj/fr/desktop/kde: kde-split-ebuilds.xml
@ 2008-07-30 12:55 Marion Age (titefleur)
0 siblings, 0 replies; 3+ messages in thread
From: Marion Age (titefleur) @ 2008-07-30 12:55 UTC (permalink / raw
To: gentoo-commits
titefleur 08/07/30 12:55:03
Added: kde-split-ebuilds.xml
Log:
Move to kde project
Revision Changes Path
1.1 xml/htdocs/proj/fr/desktop/kde/kde-split-ebuilds.xml
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/fr/desktop/kde/kde-split-ebuilds.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/fr/desktop/kde/kde-split-ebuilds.xml?rev=1.1&content-type=text/plain
Index: kde-split-ebuilds.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/desktop/kde/kde-split-ebuilds.xml,v 1.1 2008/07/30 12:55:02 titefleur Exp $ -->
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide link="/proj/fr/desktop/kde/kde-split-ebuilds.xml" lang="fr">
<title>Guide sur les ebuilds séparés de KDE</title>
<author title="Auteur">
<mail link="danarmak@gentoo.org">Dan Armak</mail>
</author>
<author title="Correcteur">
<mail link="greg_g@gentoo.org">Gregorio Guidi</mail>
</author>
<author title="Correcteur">
<mail link="philantrop@gentoo.org">Wulf C. Krueger</mail>
</author>
<author title="Traducteur">
<mail link="clement@varaldi.org">Clément Varaldi</mail>
</author>
<author title="Traducteur">
<mail link="nicolas@litchinko.fr">Nicolas Litchinko</mail>
</author>
<abstract>
Avec KDE 3.4, la notion d'ebuilds séparés a été introduite dans Portage. Ce
guide présente les raisons de cette transition, les fonctionnalités qui ont été
mises à disposition ainsi que la procédure de mise à jour à partir des anciens
ebuilds dits « monolithiques ».
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
<license/>
<version>1.12</version>
<date>2008-04-26</date>
<chapter>
<title>Les ebuilds séparés de KDE</title>
<section>
<title>Ce qu'ils sont</title>
<body>
<p>
Jusqu'à janvier 2005, les seuls ebuilds de KDE dans Portage étaient des ebuilds
monolithiques. Il n'y avait qu'une quinzaine d'ebuilds et chacun installait de
nombreuses applications (<c>kdebase</c>, <c>kdenetwork</c>...) qui, en réalité,
ne dépendaient pas les unes des autres. Ce n'était vraiment une situation ni
idéale, ni très conforme à l'esprit Gentoo, mais cela a été toléré pendant
longtemps.
</p>
<p>
Les nouveaux ebuilds « séparés » (pour <c>konqueror</c>,
<c>kmail</c>...) corrigent ce problème en proposant des ebuilds distincts pour
toutes les applications de KDE. Cela donne un total d'environ 330 nouveaux
ebuilds dans la catégorie kde-base.
</p>
<p>
Nous continuons cependant à proposer des ebuilds monolithiques pour KDE 3.5 et
ils sont utilisables en conjonction avec les versions séparées. Cependant, les
ebuilds séparés sont désormais la version par défaut et, après KDE 4.0, la
version monolithique disparaîtra.
</p>
<p>
Enfin, il faut remarquer qu'il existe également des ebuilds séparés pour Koffice
qui proposent <c>kword</c>, <c>kugar</c>, etc. comme des paquets distincts.
</p>
</body>
</section>
<section>
<title>Comment installer des ebuilds séparés</title>
<body>
<p>
À l'heure où ces lignes sont écrites, la dernière version de KDE mise à
disposition est la 3.5.8. La dernière version instable (~arch) est la 3.5.9. Les
ebuilds séparés et monolithiques pour ces deux versions sont disponibles dans
Portage. La version 4.0.x est dans l'arbre en état masqué.
</p>
<ul>
<li>
Pour installer un paquet particulier comme, par exemple, kmail, il suffit de
faire un <c>emerge kmail</c>.
</li>
<li>
Pour installer l'environnement KDE de base, qui vous permettra de vous
connecter à une simple session KDE, il faudra faire un <c>emerge
kdebase-startkde</c>.
</li>
<li>
Enfin, pour disposer de l'équivalent exact de l'un des paquets monolithiques
(par exemple, pour disposer de toutes les applications incluses dans
<c>kdebase</c> en utilisant les ebuilds séparés), vous pouvez faire un
<c>emerge kdebase-meta</c> (ou <c>kdepim-meta</c>, etc.). Pour disposer
d'absolument tous les paquets KDE, faites un <c>emerge kde-meta</c>.
</li>
</ul>
</body>
</section>
<section>
<title>Comment mettre à jour des ebuilds monolithiques vers les séparés</title>
<body>
<p>
Si vous avez installé KDE 3.3.x, vous pouvez tout simplement lancer la commande
<c>emerge kde-meta</c> pour installer les ebuilds séparés de KDE 3.5.x sans pour
autant occasionner de problème avec votre installation existante.
</p>
<p>
Si les ebuilds monolithiques de KDE 3.4.x ou 3.5.x sont installés, vous devez
les désinstaller avant d'installer les ebuilds séparés. Vous pouvez, si vous le
souhaitez, effectuer l'opération pour chaque ebuild monolithique à tour de rôle.
Vous n'avez pas besoin de désinstaller tous les ebuilds KDE à la fois.
</p>
<p>
Si vous avez un doute, souvenez-vous qu'il existe des dépendances bloquantes
en place entre chaque ebuild monolithique et les ebuilds séparés dont ils
dérivent. Portage ne permet pas de créer un état instable, donc toute
installation ou désinstallation que Portage vous permettra de faire sera OK.
</p>
</body>
</section>
<section>
<title>Avantages des ebuilds séparés</title>
<body>
<p>
Voici une liste rapide de ce que vous gagnerez à passer aux ebuilds
séparés :
</p>
<ul>
<li>
La plupart des paquets KDE ne changent pas du tout entre deux sorties
mineures de KDE. Par exemple, le passage de la version 3.3.1 à la 3.3.2
modifiera moins de 100 paquets sur 320. Les paquets séparés nous permettent
de ne créer un nouvel ebuild uniquement lorsque l'application a
effectivement subi des modifications, ce qui fait économiser (dans notre
exemple) plus de deux tiers du temps de compilation lors de la mise à jour.
</li>
<li>
Les correctifs n'affectent en général qu'un paquet bien précis. Avec les
ebuilds séparés, ils peuvent être testés, approuvés et soumis plus
rapidement et les développeurs ont moins de travail. Enfin, l'utilisateur
final passera moins de temps à faire sa mise à jour. C'est important surtout
pour les mises à jour de sécurité.
</li>
<li>
Les utilisateurs d'autres bureaux ou gestionnaires de fenêtres peuvent
installer les quelques applications KDE qui leur plaisent sans devoir passer
par l'installation d'un gros paquet d'applications qu'ils n'utiliseront pas.
Par exemple, <c>kdebase</c> ou <c>kdepim</c>.
</li>
<li>
Les utilisateurs peuvent personnaliser au mieux les paquets qu'ils
installent. Pourquoi ?
<ul>
<li>
Vous vous préoccupez du temps de compilation. <c>emerge kdebase kdepim
kdenetwork</c> prend bien trop de temps à compiler, surtout si vous ne
souhaitiez que <c>konqueror</c>, <c>kmail</c> et <c>kopete</c>.
</li>
<li>
Vous vous préoccupez de l'espace disque. Chaque paquet non utilisé
représente de l'espace disque bloqué et inutilisable sur votre disque.
Un disque avec plus d'espace disque est préférable.
</li>
<li>
Vous vous préoccupez de la sécurité du système. Tous les logiciels
installés sont des sources potentielles de vulnérabilité et il n'y a
aucune excuse pour permettre de laisser des programmes inusités traîner
sur votre système.
</li>
<li>
Vous adhérez complètement à la <uri
link="/main/en/philosophy.xml">philosophie Gentoo</uri> et vous ne
supportez pas d'avoir des applications regroupées par paquets qui
obligent les utilisateurs à installer le tout.
</li>
</ul>
</li>
<li>
Enfin, les ebuilds séparés permettent plus de flexibilité, en ce qui
concerne notamment les temps de compilation, grâce aux paramètres USE.
</li>
</ul>
</body>
</section>
<section>
<title>Utilisation conjointe des ebuilds monolithiques et séparés</title>
<body>
<p>
Les ebuilds monolithiques et séparés peuvent être librement mélangés. La seule
restriction est qu'il ne faut pas installer un ebuild monolithique en même temps
qu'un ebuild séparés qui en dérive. Des dépendances bloquantes empêchent de
faire cela, donc vous pouvez faire tout ce qu'emerge vous permet de faire.
</p>
<p>
Cela dit, il n'y a normalement aucune raison pour que vous utilisiez une
configuration mixte. En fait, mis à part certains cas comme la compilation sur
des machines lentes, vous devriez plutôt utiliser les ebuilds séparés pour tout
ce que vous souhaitez utiliser.
</p>
<p>
Les ebuilds séparés sont les ebuilds par défaut. Cela signifie que quand
d'autres ebuilds dépendent d'une application KDE, ils essayeront d'installer
l'ebuild séparé. Cela dit, l'ebuild monolithique correspondant devra également
satisfaire cette dépendance, donc vous pouvez installer l'ebuild monolithique
à la main, puis installer l'ebuild qui en dépend.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Problèmes de performance</title>
<section>
<title>Pourquoi les ebuilds séparés sont lents ?</title>
<body>
<p>
Il a été remarqué dans
<uri link="http://bugs.gentoo.org/show_bug.cgi?id=11123">ce rapport de
bogue</uri> que les ebuilds séparés sont plus longs à installer que leur version
monolithique, à cause du fait qu'il faille désarchiver et lancer le script de
configuration pour chaque paquet, au lieu d'un seul. Une installation complète
avec <c>emerge kde-meta</c> devrait prendre entre 20 et 30% plus de temps qu'une
installation classique de <c>emerge kde</c>, ce qui est difficilement acceptable
pour une compilation qui prend déjà suffisamment de temps.
</p>
<p>
Pour couronner le tout, pour le moment, les ebuilds séparés lancent toujours un
<c>make -f admin/Makefile.cvs</c> (ce qui signifie exécuter autoconf, automake,
etc. et divers scripts spécifiques à KDE). Cela ajoute une dose de lenteur à la
compilation, qui est du même ordre que l'exécution du script de configuration.
</p>
<p>
Enfin, un ebuild séparé doit extraire des fichiers spécifiques depuis une
archive tar imposante. Ceci est plus lent que l'extraction d'une archive tar
dédiée de plus petite taille. Cependant, créer de telles archives pour le
système de compilation de KDE 3.x qui est basé sur les autotools est difficile.
</p>
<p>
Il est bon de rappeler ici que grâce aux ebuilds séparés, une mise à jour de KDE
aura un temps de compilation bien inférieur à cette même mise à jour en
utilisant les ebuilds monolithiques. Ces bénéfices masquent souvent les
désagréments constatés lors de l'installation initiale.
</p>
<p>
Finalement, installer tout KDE n'a de sens que si vous voulez explorer et
tester l'ensemble des paquets disponibles ou si vous voulez mettre en place un
environnement multi-utilisateur. Cela dit, la plupart des utilisateurs
n'utilisent qu'une poignée des plus de 300 applications KDE disponibles. Ceux
qui se préoccupent sérieusement du temps de compilation, comme les propriétaires
de vieilles machines, peuvent gagner plus de temps à choisir minutieusement les
paquets à installer qu'à installer les ebuilds monolithiques.
</p>
</body>
</section>
<section>
<title>Comment va-t-on faire pour accélérer tout ça ?</title>
<body>
<p>
La plupart sinon tous les problèmes de performance des ebuilds séparés sont
liés aux autotools - autoconf, automake et d'autres outils qui gèrent le
processus de compilation (<c>./configure;make;make install</c>) de KDE 3.x.
</p>
<p>
KDE 4 a adopté un processus de compilation complètement différent, cmake, qui,
entre autres choses, réduit considérablement le temps que prend son équivalent
d'un <c>make -f admin/Makefile.common; ./configure</c>.
</p>
</body>
</section>
</chapter>
<chapter>
<title>FAQ des ebuilds séparés</title>
<section>
<title>Pourquoi est-ce que certains paquets séparés ne sont pas mis à jour lors
de la sortie de nouvelles versions ?</title>
<body>
<p>
Comme expliqué précédemment, toutes les applications ne sont pas mises à jour
entre deux versions mineures de KDE, et par conséquent toutes les applications
ne voient pas la création d'une nouvelle version de leur ebuild. Par exemple,
libkdenetwork n'a pas été modifiée pour la version 3.5.0_beta2, donc le dernier
ebuild disponible porte le numéro de version 3.5_beta1.
</p>
<p>
Ceci est fait simplement pour réduire le temps de compilation lors d'une mise à
jour. Si nous avions créé un ebuild libkdenetwork-3.5.0_beta2, cela aurait
installé exactement les mêmes fichiers que l'ebuild pour la version 3.5_beta1.
Les diverses dépendances sont mises à jour pour que tout fonctionne correctement
(i.e. aucun ebuild ne dépendra de libkdenetwork-3.5.0_beta2).
</p>
<p>
Notez que, à cause de cela, si vous voulez installer des versions masquées de
KDE, il se peut que vous ayez besoin de démasquer certains paquets d'une version
précédente de KDE, s'ils sont également masqués. Veuillez lire <uri
link="https://bugs.gentoo.org/125126">ce bogue</uri> pour plus de détails.
</p>
</body>
</section>
<section>
<title>Est-ce qu'on ne peut pas déjà faire ceci avec
DO_NOT_COMPILE ?</title>
<body>
<p>
DO_NOT_COMPILE est une variable d'environnement interne utilisée lors de la
compilation de KDE. Elle permet de supprimer de la compilation certains
sous-répertoires choisis à l'avance. Certains utilisateurs s'en servent pour ne
compiler qu'une partie d'un ebuild KDE monolithique. Par exemple, exécuter
<c>DO_NOT_COMPILE=konqueror emerge kdebase</c> devrait installer la base de KDE
sans installer l'application <c>konqueror</c>.
</p>
<p>
Cependant, DO_NOT_COMPILE n'a jamais eu pour but de permettre d'intervenir dans
les opérations de compilation du gestionnaire de paquets. Cela ne fonctionne pas
correctement, peut casser votre système et n'a jamais été supporté. Nous
demandons donc de ne surtout pas l'utiliser.
</p>
<p>
Voici quelques-uns des problèmes de DO_NOT_COMPILE :
</p>
<ul>
<li>
Il casse complètement le système de recherche de dépendances de Portage.
Portage ne connaît pas DO_NOT_COMPILE et pense que l'ensemble du paquet
monolithique a été installé et peut satisfaire les dépendances d'autres
paquets. Cela peut amener ces autres paquets à ne pas pouvoir s'installer
ou ne pas pouvoir s'exécuter.
</li>
<li>
Il oblige l'utilisateur à connaître le nom et le sens de tous les différents
sous répertoires des modules KDE. Peu d'utilisateurs en connaissent le sens,
à moins d'être développeur KDE, vous avez peu de chances d'en faire partie.
Il y a peu de chances pour que vous utilisiez alors DO_NOT_COMPILE
correctement.
</li>
<li>
Les sous-répertoires de modules KDE peuvent avoir des dépendances entre
eux, nécessitent parfois un ordre précis de compilation, nécessitent la
présence d'un autre répertoire même s'il n'a pas besoin d'être installé,
etc. Nous avons passé beaucoup de temps sur les ebuilds séparés pour qu'ils
puissent fonctionner correctement dans ce sens. DO_NOT_COMPILE n'est pas un
outil assez fin pour obtenir des résultats aussi bons que les ebuilds
séparés, même si l'utilisateur a une connaissance suffisante pour pouvoir
le manipuler. La seule chose que cette variable vous permette de faire est
d'enlever de la compilation quelques applications. Il est pratiquement
impossible de l'utiliser pour installer deux ou trois applications à partir
de modules comme <c>kdebase</c> ou <c>kdepim</c>.
</li>
<li>
Si j'ai installé kmail hier et que je veux ajouter korn aujourd'hui, en
utilisant DO_NOT_COMPILE, il faudra recompiler kmail également. Cela
signifie que DO_NOT_COMPILE sera toujours plus lent que les ebuilds séparés.
</li>
<li>
DO_NOT_COMPILE ne peut pas être utilisé pour créer des paquets précompilés
(comme par exemple les GRP) contenant des applications individuelles de KDE.
</li>
</ul>
</body>
</section>
<section>
<title>Est-ce que vous n'en demanderiez pas un peu trop aux mainteneurs KDE de
Gentoo ?</title>
<body>
<p>
Curieusement, cette question est souvent revenue. Je suis content de voir que
les utilisateurs sont aussi prévenants à l'égard des mainteneurs. Laissez-moi
vous dire, pour l'occasion, que nous avons nous-même choisi la voie des ebuilds
séparés. Nous croyons que nous seront capables de maintenir les paquets avec la
même qualité qu'actuellement. Rien ne nous empêchera de faire les ebuilds
séparés.
</p>
<p>
Pour être plus juste, je devrais ajouter que des mainteneurs d'autres
architectures se sont effectivement plaints de l'augmentation de charge de
travail, de tests et de gestion des mots-clefs sur autant d'ebuilds séparés.
Nous travaillons actuellement pour résoudre ce problème et c'est la raison
essentielle qui fait que les ebuilds monolithiques seront en fait toujours
disponibles pour KDE 3.5.
</p>
</body>
</section>
<section>
<title>Allez-vous supprimer les ebuilds monolithiques ?</title>
<body>
<p>
Nous essaierons de le faire. Cela dit, pour toutes les versions de KDE 3.x, nous
aurons à la fois des ebuilds monolithiques et séparés. Pour KDE4, nous ne
fournissons plus d'ebuilds monolithiques.
</p>
<p>
Si vous préférez les ebuilds monolithiques aux séparés, merci de nous faire part
de <uri link="http://bugs.gentoo.org">vos raisons</uri>.
</p>
</body>
</section>
<section>
<title>Il y a trop d'ebuilds ! Comment faire pour trouver celui dont j'ai
besoin ?</title>
<body>
<p>
Tout d'abord, si vous savez que le paquet que vous recherchez vient avec kdebase
vous pouvez toujours faire un <c>emerge kdebase-meta</c>, qui vous permettra
de faire un peu la même chose que si vous installiez la version monolithique de
<c>kdebase</c>.
</p>
<p>
Évidemment, vous pouvez utiliser tous les moyens habituels de recherche de
paquet. Trouveriez-vous votre ebuild si c'était une application Gnome ? Le
minimum est d'avoir le nom de l'application que vous recherchez.
</p>
<p>
La situation pourrait peut-être être améliorée en ajoutant certains ebuilds de
type -meta. Ils sont à considérer comme des listes de dépendances, donc ça ne
nous coûte rien d'en créer. Mais nous n'avons pas encore décidé si nous le
ferons ou pas. De même, il serait bien que Portage puisse supporter certaines
fonctionnalités liées aux ebuilds -meta avant de se mettre à les utiliser de
manière excessive.
</p>
</body>
</section>
<section>
<title>Comment puis-je lister/désinstaller tous les ebuilds séparés qui dérivent
d'un paquet donné ?</title>
<body>
<p>
L'objectif ici est d'obtenir une liste de tous les ebuilds séparés de KDE
dérivant de, mettons, l'ebuild monolithique <c>kdebase</c>. Encore une fois, une
implémentation correcte (comme proposé dans la <uri
link="/proj/en/glep/glep-0021.html">GLEP 21</uri>) pourrait rendre cette
opération triviale. Mais, pour le moment, vous devrez jouer avec des détails
qui concernent l'implémentation des eclass KDE. Donc si vous les utilisez pour
un script qui n'est pas à usage privé, merci de nous le signaler.
</p>
<p>
kde-functions.eclass définit des fonctions nommées get-parent-package() et
get-child-packages() qui font la traduction pour vous. Ces deux fonctions sont
un bon moyen d'obtenir la liste demandée à partir d'un ebuild ou d'un script
bash externe. Voici un exemple :
</p>
<pre caption="Exemple d'utilisation des fonctions de kde-functions">
$ <i>function die() { echo $@; }</i>
<comment># appelée pour afficher les erreurs</comment>
$ <i>source /usr/portage/eclass/kde-functions.eclass</i>
$ <i>get-parent-package konqueror</i> <comment># ne fonctionnera pas, vous
devez spécifier le nom complet</comment>
Package konqueror not found in KDE_DERIVATION_MAP, please report bug
<comment># erreur affichée</comment>
$ <i>get-parent-package kde-base/konqueror</i> <comment># nom complet</comment>
kde-base/kdebase <comment># résultat affiché</comment>
$ <i>get-child-packages kde-base/kdebase</i>
<comment>(Une longue liste de paquets s'affiche ci-dessous.)</comment>
</pre>
<p>
Si votre script n'est pas en bash, vous pouvez récupérer dans
kde-functions.eclass la définition (sur plusieurs lignes) de la variable
KDE_DERIVATION_MAP que les fonctions citées plus haut utilisent. Cette variable
contient une liste de mots séparés par des espaces et chaque paire de mots
consécutifs permet de faire la correspondance entre un paquet parent et un
ebuild séparé qui hérite de celui-ci.
</p>
</body>
</section>
</chapter>
</guide>
^ permalink raw reply [flat|nested] 3+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/fr/desktop/kde: kde-split-ebuilds.xml
@ 2008-12-09 15:57 Marion Age (titefleur)
0 siblings, 0 replies; 3+ messages in thread
From: Marion Age (titefleur) @ 2008-12-09 15:57 UTC (permalink / raw
To: gentoo-commits
titefleur 08/12/09 15:57:10
Modified: kde-split-ebuilds.xml
Log:
Sync to 1.3
Revision Changes Path
1.2 xml/htdocs/proj/fr/desktop/kde/kde-split-ebuilds.xml
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/fr/desktop/kde/kde-split-ebuilds.xml?rev=1.2&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/fr/desktop/kde/kde-split-ebuilds.xml?rev=1.2&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/fr/desktop/kde/kde-split-ebuilds.xml?r1=1.1&r2=1.2
Index: kde-split-ebuilds.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/fr/desktop/kde/kde-split-ebuilds.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- kde-split-ebuilds.xml 30 Jul 2008 12:55:02 -0000 1.1
+++ kde-split-ebuilds.xml 9 Dec 2008 15:57:10 -0000 1.2
@@ -1,5 +1,5 @@
<?xml version="1.0" encoding="UTF-8"?>
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/desktop/kde/kde-split-ebuilds.xml,v 1.1 2008/07/30 12:55:02 titefleur Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/desktop/kde/kde-split-ebuilds.xml,v 1.2 2008/12/09 15:57:10 titefleur Exp $ -->
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide link="/proj/fr/desktop/kde/kde-split-ebuilds.xml" lang="fr">
@@ -21,6 +21,9 @@
<author title="Traducteur">
<mail link="nicolas@litchinko.fr">Nicolas Litchinko</mail>
</author>
+<author title="Traducteur">
+ <mail link="titefleur"/>
+</author>
<abstract>
Avec KDE 3.4, la notion d'ebuilds séparés a été introduite dans Portage. Ce
@@ -33,8 +36,8 @@
<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
<license/>
-<version>1.12</version>
-<date>2008-04-26</date>
+<version>1.13</version>
+<date>2008-11-22</date>
<chapter>
<title>Les ebuilds séparés de KDE</title>
@@ -59,10 +62,10 @@
</p>
<p>
-Nous continuons cependant à proposer des ebuilds monolithiques pour KDE 3.5 et
-ils sont utilisables en conjonction avec les versions séparées. Cependant, les
-ebuilds séparés sont désormais la version par défaut et, après KDE 4.0, la
-version monolithique disparaîtra.
+Nous continuons cependant à proposer des ebuilds monolithiques pour KDE 3.5
+(jusqu'à la version 3.5.9) et ils sont utilisables en conjonction avec les
+versions séparées. Cependant, les ebuilds séparés sont désormais la version par
+défaut et, après KDE 3.5.9, la version monolithique disparaîtra.
</p>
<p>
@@ -78,9 +81,9 @@
<p>
À l'heure où ces lignes sont écrites, la dernière version de KDE mise à
-disposition est la 3.5.8. La dernière version instable (~arch) est la 3.5.9. Les
+disposition est la 3.5.9. La dernière version instable (~arch) est la 3.5.10. Les
ebuilds séparés et monolithiques pour ces deux versions sont disponibles dans
-Portage. La version 4.0.x est dans l'arbre en état masqué.
+Portage. La version 4.1.x est dans l'arbre en état masqué.
</p>
<ul>
@@ -109,12 +112,6 @@
<body>
<p>
-Si vous avez installé KDE 3.3.x, vous pouvez tout simplement lancer la commande
-<c>emerge kde-meta</c> pour installer les ebuilds séparés de KDE 3.5.x sans pour
-autant occasionner de problème avec votre installation existante.
-</p>
-
-<p>
Si les ebuilds monolithiques de KDE 3.4.x ou 3.5.x sont installés, vous devez
les désinstaller avant d'installer les ebuilds séparés. Vous pouvez, si vous le
souhaitez, effectuer l'opération pour chaque ebuild monolithique à tour de rôle.
@@ -325,7 +322,7 @@
Notez que, à cause de cela, si vous voulez installer des versions masquées de
KDE, il se peut que vous ayez besoin de démasquer certains paquets d'une version
précédente de KDE, s'ils sont également masqués. Veuillez lire <uri
- link="https://bugs.gentoo.org/125126">ce bogue</uri> pour plus de détails.
+link="https://bugs.gentoo.org/125126">ce bogue</uri> pour plus de détails.
</p>
</body>
@@ -427,8 +424,9 @@
<body>
<p>
-Nous essaierons de le faire. Cela dit, pour toutes les versions de KDE 3.x, nous
-aurons à la fois des ebuilds monolithiques et séparés. Pour KDE4, nous ne
+Nous essaierons de le faire. Cela dit, pour toutes les versions de KDE 3.x
+jusqu'à la version 3.5.9, nous fournissons à la fois des ebuilds monolithiques
+et séparés. Pour KDE 3.5.10 et plus récents, ainsi que KDE 4 nous ne
fournissons plus d'ebuilds monolithiques.
</p>
^ permalink raw reply [flat|nested] 3+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/fr/desktop/kde: kde-split-ebuilds.xml
@ 2010-05-05 15:37 Marion Age (titefleur)
0 siblings, 0 replies; 3+ messages in thread
From: Marion Age (titefleur) @ 2010-05-05 15:37 UTC (permalink / raw
To: gentoo-commits
titefleur 10/05/05 15:37:16
Removed: kde-split-ebuilds.xml
Log:
Sync to 1.4
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-05-05 15:37 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-12-09 15:57 [gentoo-commits] gentoo commit in xml/htdocs/proj/fr/desktop/kde: kde-split-ebuilds.xml Marion Age (titefleur)
-- strict thread matches above, loose matches on Subject: below --
2010-05-05 15:37 Marion Age (titefleur)
2008-07-30 12:55 Marion Age (titefleur)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox