| 1 |
titefleur 08/07/30 12:58:09 |
| 2 |
|
| 3 |
Modified: kde-split-ebuilds.xml |
| 4 |
Log: |
| 5 |
Sync to 1.16 (move to its project directory) |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.11 xml/htdocs/doc/fr/kde-split-ebuilds.xml |
| 9 |
|
| 10 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/fr/kde-split-ebuilds.xml?rev=1.11&view=markup |
| 11 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/fr/kde-split-ebuilds.xml?rev=1.11&content-type=text/plain |
| 12 |
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/fr/kde-split-ebuilds.xml?r1=1.10&r2=1.11 |
| 13 |
|
| 14 |
Index: kde-split-ebuilds.xml |
| 15 |
=================================================================== |
| 16 |
RCS file: /var/cvsroot/gentoo/xml/htdocs/doc/fr/kde-split-ebuilds.xml,v |
| 17 |
retrieving revision 1.10 |
| 18 |
retrieving revision 1.11 |
| 19 |
diff -u -r1.10 -r1.11 |
| 20 |
--- kde-split-ebuilds.xml 18 Feb 2008 23:23:50 -0000 1.10 |
| 21 |
+++ kde-split-ebuilds.xml 30 Jul 2008 12:58:08 -0000 1.11 |
| 22 |
@@ -1,8 +1,8 @@ |
| 23 |
<?xml version="1.0" encoding="UTF-8"?> |
| 24 |
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/fr/kde-split-ebuilds.xml,v 1.10 2008/02/18 23:23:50 titefleur Exp $ --> |
| 25 |
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/fr/kde-split-ebuilds.xml,v 1.11 2008/07/30 12:58:08 titefleur Exp $ --> |
| 26 |
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
| 27 |
|
| 28 |
-<guide link="/doc/fr/kde-split-ebuilds.xml" lang="fr"> |
| 29 |
+<guide redirect="/proj/fr/desktop/kde/kde-split-ebuilds.xml"> |
| 30 |
|
| 31 |
<title>Guide sur les ebuilds séparés de KDE</title> |
| 32 |
|
| 33 |
@@ -31,479 +31,17 @@ |
| 34 |
<!-- See http://creativecommons.org/licenses/by-sa/2.0 --> |
| 35 |
<license/> |
| 36 |
|
| 37 |
-<version>1.11</version> |
| 38 |
-<date>2008-01-16</date> |
| 39 |
+<version>2</version> |
| 40 |
+<date>2008-04-26</date> |
| 41 |
|
| 42 |
<chapter> |
| 43 |
-<title>Les ebuilds séparés de KDE</title> |
| 44 |
+<title>Déplacé</title> |
| 45 |
<section> |
| 46 |
-<title>Ce qu'ils sont</title> |
| 47 |
<body> |
| 48 |
|
| 49 |
<p> |
| 50 |
-Jusqu'à janvier 2005, les seuls ebuilds de KDE dans Portage étaient des ebuilds |
| 51 |
-monolithiques. Il n'y avait qu'une quinzaine d'ebuilds et chacun installait de |
| 52 |
-nombreuses applications (<c>kdebase</c>, <c>kdenetwork</c>...) qui, en réalité, |
| 53 |
-ne dépendaient pas les unes des autres. Ce n'était vraiment une situation ni |
| 54 |
-idéale, ni très conforme à l'esprit Gentoo, mais cela a été toléré pendant |
| 55 |
-longtemps. |
| 56 |
-</p> |
| 57 |
- |
| 58 |
-<p> |
| 59 |
-Les nouveaux ebuilds « séparés » (pour <c>konqueror</c>, |
| 60 |
-<c>kmail</c>...) corrigent ce problème en proposant des ebuilds distincts pour |
| 61 |
-toutes les applications de KDE. Cela donne un total d'environ 330 nouveaux |
| 62 |
-ebuilds dans la catégorie kde-base. |
| 63 |
-</p> |
| 64 |
- |
| 65 |
-<p> |
| 66 |
-Nous continuons cependant à proposer des ebuilds monolithiques pour KDE 3.5 et |
| 67 |
-ils sont utilisables en conjonction avec les versions séparées. Cependant, les |
| 68 |
-ebuilds séparés sont désormais la version par défaut et, après KDE 4.0, la |
| 69 |
-version monolithique disparaîtra. |
| 70 |
-</p> |
| 71 |
- |
| 72 |
-<p> |
| 73 |
-Enfin, il faut remarquer qu'il existe également des ebuilds séparés pour Koffice |
| 74 |
-qui proposent <c>kword</c>, <c>kugar</c>, etc. comme des paquets distincts. |
| 75 |
-</p> |
| 76 |
- |
| 77 |
-</body> |
| 78 |
-</section> |
| 79 |
-<section> |
| 80 |
-<title>Comment installer des ebuilds séparés</title> |
| 81 |
-<body> |
| 82 |
- |
| 83 |
-<p> |
| 84 |
-À l'heure où ces lignes sont écrites, la dernière version de KDE mise à |
| 85 |
-disposition est la 3.5.7. La dernière version instable (~arch) est la 3.5.8. Les |
| 86 |
-ebuilds séparés et monolithiques pour ces deux versions sont disponibles dans |
| 87 |
-Portage. La version 4.0.0 est sur le point d'entrer dans l'arbre en état masqué. |
| 88 |
-</p> |
| 89 |
- |
| 90 |
-<ul> |
| 91 |
- <li> |
| 92 |
- Pour installer un paquet particulier comme, par exemple, kmail, il suffit de |
| 93 |
- faire un <c>emerge kmail</c>. |
| 94 |
- </li> |
| 95 |
- <li> |
| 96 |
- Pour installer l'environnement KDE de base, qui vous permettra de vous |
| 97 |
- connecter à une simple session KDE, il faudra faire un <c>emerge |
| 98 |
- kdebase-startkde</c>. |
| 99 |
- </li> |
| 100 |
- <li> |
| 101 |
- Enfin, pour disposer de l'équivalent exact de l'un des paquets monolithiques |
| 102 |
- (par exemple, pour disposer de toutes les applications incluses dans |
| 103 |
- <c>kdebase</c> en utilisant les ebuilds séparés), vous pouvez faire un |
| 104 |
- <c>emerge kdebase-meta</c> (ou <c>kdepim-meta</c>, etc.). Pour disposer |
| 105 |
- d'absolument tous les paquets KDE, faites un <c>emerge kde-meta</c>. |
| 106 |
- </li> |
| 107 |
-</ul> |
| 108 |
- |
| 109 |
-</body> |
| 110 |
-</section> |
| 111 |
-<section> |
| 112 |
-<title>Comment mettre à jour des ebuilds monolithiques vers les séparés</title> |
| 113 |
-<body> |
| 114 |
- |
| 115 |
-<p> |
| 116 |
-Si vous avez installé KDE 3.3.x, vous pouvez tout simplement lancer la commande |
| 117 |
-<c>emerge kde-meta</c> pour installer les ebuilds séparés de KDE 3.5.x sans pour |
| 118 |
-autant occasionner de problème avec votre installation existante. |
| 119 |
-</p> |
| 120 |
- |
| 121 |
-<p> |
| 122 |
-Si les ebuilds monolithiques de KDE 3.4.x ou 3.5.x sont installés, vous devez |
| 123 |
-les désinstaller avant d'installer les ebuilds séparés. Vous pouvez, si vous le |
| 124 |
-souhaitez, effectuer l'opération pour chaque ebuild monolithique à tour de rôle. |
| 125 |
-Vous n'avez pas besoin de désinstaller tous les ebuilds KDE à la fois. |
| 126 |
-</p> |
| 127 |
- |
| 128 |
-<p> |
| 129 |
-Si vous avez un doute, souvenez-vous qu'il existe des dépendances bloquantes |
| 130 |
-en place entre chaque ebuild monolithique et les ebuilds séparés dont ils |
| 131 |
-dérivent. Portage ne permet pas de créer un état instable, donc toute |
| 132 |
-installation ou désinstallation que Portage vous permettra de faire sera OK. |
| 133 |
-</p> |
| 134 |
- |
| 135 |
-</body> |
| 136 |
-</section> |
| 137 |
-<section> |
| 138 |
-<title>Avantages des ebuilds séparés</title> |
| 139 |
-<body> |
| 140 |
- |
| 141 |
-<p> |
| 142 |
-Voici une liste rapide de ce que vous gagnerez à passer aux ebuilds |
| 143 |
-séparés : |
| 144 |
-</p> |
| 145 |
- |
| 146 |
-<ul> |
| 147 |
- <li> |
| 148 |
- La plupart des paquets KDE ne changent pas du tout entre deux sorties |
| 149 |
- mineures de KDE. Par exemple, le passage de la version 3.3.1 à la 3.3.2 |
| 150 |
- modifiera moins de 100 paquets sur 320. Les paquets séparés nous permettent |
| 151 |
- de ne créer un nouvel ebuild uniquement lorsque l'application a |
| 152 |
- effectivement subi des modifications, ce qui fait économiser (dans notre |
| 153 |
- exemple) plus de deux tiers du temps de compilation lors de la mise à jour. |
| 154 |
- </li> |
| 155 |
- <li> |
| 156 |
- Les correctifs n'affectent en général qu'un paquet bien précis. Avec les |
| 157 |
- ebuilds séparés, ils peuvent être testés, approuvés et soumis plus |
| 158 |
- rapidement et les développeurs ont moins de travail. Enfin, l'utilisateur |
| 159 |
- final passera moins de temps à faire sa mise à jour. C'est important surtout |
| 160 |
- pour les mises à jour de sécurité. |
| 161 |
- </li> |
| 162 |
- <li> |
| 163 |
- Les utilisateurs d'autres bureaux ou gestionnaires de fenêtres peuvent |
| 164 |
- installer les quelques applications KDE qui leur plaisent sans devoir passer |
| 165 |
- par l'installation d'un gros paquet d'applications qu'ils n'utiliseront pas. |
| 166 |
- Par exemple, <c>kdebase</c> ou <c>kdepim</c>. |
| 167 |
- </li> |
| 168 |
- <li> |
| 169 |
- Les utilisateurs peuvent personnaliser au mieux les paquets qu'ils |
| 170 |
- installent. Pourquoi ? |
| 171 |
- |
| 172 |
- <ul> |
| 173 |
- <li> |
| 174 |
- Vous vous préoccupez du temps de compilation. <c>emerge kdebase kdepim |
| 175 |
- kdenetwork</c> prend bien trop de temps à compiler, surtout si vous ne |
| 176 |
- souhaitiez que <c>konqueror</c>, <c>kmail</c> et <c>kopete</c>. |
| 177 |
- </li> |
| 178 |
- <li> |
| 179 |
- Vous vous préoccupez de l'espace disque. Chaque paquet non utilisé |
| 180 |
- représente de l'espace disque bloqué et inutilisable sur votre disque. |
| 181 |
- Un disque avec plus d'espace disque est préférable. |
| 182 |
- </li> |
| 183 |
- <li> |
| 184 |
- Vous vous préoccupez de la sécurité du système. Tous les logiciels |
| 185 |
- installés sont des sources potentielles de vulnérabilité et il n'y a |
| 186 |
- aucune excuse pour permettre de laisser des programmes inusités traîner |
| 187 |
- sur votre système. |
| 188 |
- </li> |
| 189 |
- <li> |
| 190 |
- Vous adhérez complètement à la <uri |
| 191 |
- link="/main/en/philosophy.xml">philosophie Gentoo</uri> et vous ne |
| 192 |
- supportez pas d'avoir des applications regroupées par paquets qui |
| 193 |
- obligent les utilisateurs à installer le tout. |
| 194 |
- </li> |
| 195 |
- </ul> |
| 196 |
- </li> |
| 197 |
- <li> |
| 198 |
- Enfin, les ebuilds séparés permettent plus de flexibilité, en ce qui |
| 199 |
- concerne notamment les temps de compilation, grâce aux paramètres USE. |
| 200 |
- </li> |
| 201 |
-</ul> |
| 202 |
- |
| 203 |
-</body> |
| 204 |
-</section> |
| 205 |
-<section> |
| 206 |
-<title>Utilisation conjointe des ebuilds monolithiques et séparés</title> |
| 207 |
-<body> |
| 208 |
- |
| 209 |
-<p> |
| 210 |
-Les ebuilds monolithiques et séparés peuvent être librement mélangés. La seule |
| 211 |
-restriction est qu'il ne faut pas installer un ebuild monolithique en même temps |
| 212 |
-qu'un ebuild séparés qui en dérive. Des dépendances bloquantes empêchent de |
| 213 |
-faire cela, donc vous pouvez faire tout ce qu'emerge vous permet de faire. |
| 214 |
-</p> |
| 215 |
- |
| 216 |
-<p> |
| 217 |
-Cela dit, il n'y a normalement aucune raison pour que vous utilisiez une |
| 218 |
-configuration mixte. En fait, mis à part certains cas comme la compilation sur |
| 219 |
-des machines lentes, vous devriez plutôt utiliser les ebuilds séparés pour tout |
| 220 |
-ce que vous souhaitez utiliser. |
| 221 |
-</p> |
| 222 |
- |
| 223 |
-<p> |
| 224 |
-Les ebuilds séparés sont les ebuilds par défaut. Cela signifie que quand |
| 225 |
-d'autres ebuilds dépendent d'une application KDE, ils essayeront d'installer |
| 226 |
-l'ebuild séparé. Cela dit, l'ebuild monolithique correspondant devra également |
| 227 |
-satisfaire cette dépendance, donc vous pouvez installer l'ebuild monolithique |
| 228 |
-à la main, puis installer l'ebuild qui en dépend. |
| 229 |
-</p> |
| 230 |
- |
| 231 |
-</body> |
| 232 |
-</section> |
| 233 |
-</chapter> |
| 234 |
- |
| 235 |
-<chapter> |
| 236 |
-<title>Problèmes de performance</title> |
| 237 |
-<section> |
| 238 |
-<title>Pourquoi les ebuilds séparés sont lents ?</title> |
| 239 |
-<body> |
| 240 |
- |
| 241 |
-<p> |
| 242 |
-Il a été remarqué dans |
| 243 |
-<uri link="http://bugs.gentoo.org/show_bug.cgi?id=11123">ce rapport de |
| 244 |
-bogue</uri> que les ebuilds séparés sont plus longs à installer que leur version |
| 245 |
-monolithique, à cause du fait qu'il faille désarchiver et lancer le script de |
| 246 |
-configuration pour chaque paquet, au lieu d'un seul. Une installation complète |
| 247 |
-avec <c>emerge kde-meta</c> devrait prendre entre 20 et 30% plus de temps qu'une |
| 248 |
-installation classique de <c>emerge kde</c>, ce qui est difficilement acceptable |
| 249 |
-pour une compilation qui prend déjà suffisamment de temps. |
| 250 |
-</p> |
| 251 |
- |
| 252 |
-<p> |
| 253 |
-Pour couronner le tout, pour le moment, les ebuilds séparés lancent toujours un |
| 254 |
-<c>make -f admin/Makefile.cvs</c> (ce qui signifie exécuter autoconf, automake, |
| 255 |
-etc. et divers scripts spécifiques à KDE). Cela ajoute une dose de lenteur à la |
| 256 |
-compilation, qui est du même ordre que l'exécution du script de configuration. |
| 257 |
-</p> |
| 258 |
- |
| 259 |
-<p> |
| 260 |
-Enfin, un ebuild séparé doit extraire des fichiers spécifiques depuis une |
| 261 |
-archive tar imposante. Ceci est plus lent que l'extraction d'une archive tar |
| 262 |
-dédiée de plus petite taille. Cependant, créer de telles archives pour le |
| 263 |
-système de compilation de KDE 3.x qui est basé sur les autotools est difficile. |
| 264 |
-</p> |
| 265 |
- |
| 266 |
-<p> |
| 267 |
-Il est bon de rappeler ici que grâce aux ebuilds séparés, une mise à jour de KDE |
| 268 |
-aura un temps de compilation bien inférieur à cette même mise à jour en |
| 269 |
-utilisant les ebuilds monolithiques. Ces bénéfices masquent souvent les |
| 270 |
-désagréments constatés lors de l'installation initiale. |
| 271 |
-</p> |
| 272 |
- |
| 273 |
-<p> |
| 274 |
-Finalement, installer tout KDE n'a de sens que si vous voulez explorer et |
| 275 |
-tester l'ensemble des paquets disponibles ou si vous voulez mettre en place un |
| 276 |
-environnement multi-utilisateur. Cela dit, la plupart des utilisateurs |
| 277 |
-n'utilisent qu'une poignée des plus de 300 applications KDE disponibles. Ceux |
| 278 |
-qui se préoccupent sérieusement du temps de compilation, comme les propriétaires |
| 279 |
-de vieilles machines, peuvent gagner plus de temps à choisir minutieusement les |
| 280 |
-paquets à installer qu'à installer les ebuilds monolithiques. |
| 281 |
-</p> |
| 282 |
- |
| 283 |
-</body> |
| 284 |
-</section> |
| 285 |
-<section> |
| 286 |
-<title>Comment va-t-on faire pour accélérer tout ça ?</title> |
| 287 |
-<body> |
| 288 |
- |
| 289 |
-<p> |
| 290 |
-La plupart sinon tous les problèmes de performance des ebuilds séparés sont |
| 291 |
-liés aux autotools - autoconf, automake et d'autres outils qui gèrent le |
| 292 |
-processus de compilation (<c>./configure;make;make install</c>) de KDE 3.x. |
| 293 |
-</p> |
| 294 |
- |
| 295 |
-<p> |
| 296 |
-KDE 4 devrait adopter un processus de compilation complètement différent qui, |
| 297 |
-entre autres choses, réduira considérablement le temps que prendra son |
| 298 |
-équivalent d'un <c>make -f admin/Makefile.common; ./configure</c>. Ceci |
| 299 |
-devrait également faciliter la création de petites archives tar pour chaque |
| 300 |
-ebuild séparé en réduisant le coût de la génération de son équivalent d'un |
| 301 |
-script de configuration (s'il en est). |
| 302 |
-</p> |
| 303 |
- |
| 304 |
-</body> |
| 305 |
-</section> |
| 306 |
-</chapter> |
| 307 |
- |
| 308 |
-<chapter> |
| 309 |
-<title>FAQ des ebuilds séparés</title> |
| 310 |
-<section> |
| 311 |
-<title>Pourquoi est-ce que certains paquets séparés ne sont pas mis à jour lors |
| 312 |
-de la sortie de nouvelles versions ?</title> |
| 313 |
-<body> |
| 314 |
- |
| 315 |
-<p> |
| 316 |
-Comme expliqué précédemment, toutes les applications ne sont pas mises à jour |
| 317 |
-entre deux versions mineures de KDE, et par conséquent toutes les applications |
| 318 |
-ne voient pas la création d'une nouvelle version de leur ebuild. Par exemple, |
| 319 |
-libkdenetwork n'a pas été modifiée pour la version 3.5.0_beta2, donc le dernier |
| 320 |
-ebuild disponible porte le numéro de version 3.5_beta1. |
| 321 |
-</p> |
| 322 |
- |
| 323 |
-<p> |
| 324 |
-Ceci est fait simplement pour réduire le temps de compilation lors d'une mise à |
| 325 |
-jour. Si nous avions créé un ebuild libkdenetwork-3.5.0_beta2, cela aurait |
| 326 |
-installé exactement les mêmes fichiers que l'ebuild pour la version 3.5_beta1. |
| 327 |
-Les diverses dépendances sont mises à jour pour que tout fonctionne correctement |
| 328 |
-(i.e. aucun ebuild ne dépendra de libkdenetwork-3.5.0_beta2). |
| 329 |
-</p> |
| 330 |
- |
| 331 |
-</body> |
| 332 |
-</section> |
| 333 |
- |
| 334 |
-<section> |
| 335 |
-<title>Est-ce qu'on ne peut pas déjà faire ceci avec |
| 336 |
-DO_NOT_COMPILE ?</title> |
| 337 |
-<body> |
| 338 |
- |
| 339 |
-<p> |
| 340 |
-DO_NOT_COMPILE est une variable d'environnement interne utilisée lors de la |
| 341 |
-compilation de KDE. Elle permet de supprimer de la compilation certains |
| 342 |
-sous-répertoires choisis à l'avance. Certains utilisateurs s'en servent pour ne |
| 343 |
-compiler qu'une partie d'un ebuild KDE monolithique. Par exemple, exécuter |
| 344 |
-<c>DO_NOT_COMPILE=konqueror emerge kdebase</c> devrait installer la base de KDE |
| 345 |
-sans installer l'application <c>konqueror</c>. |
| 346 |
-</p> |
| 347 |
- |
| 348 |
-<p> |
| 349 |
-Cependant, DO_NOT_COMPILE n'a jamais eu pour but de permettre d'intervenir dans |
| 350 |
-les opérations de compilation du gestionnaire de paquets. Cela ne fonctionne pas |
| 351 |
-correctement, peut casser votre système et n'a jamais été supporté. Nous |
| 352 |
-demandons donc de ne surtout pas l'utiliser. |
| 353 |
-</p> |
| 354 |
- |
| 355 |
-<p> |
| 356 |
-Voici quelques-uns des problèmes de DO_NOT_COMPILE : |
| 357 |
-</p> |
| 358 |
- |
| 359 |
-<ul> |
| 360 |
- <li> |
| 361 |
- Il casse complètement le système de recherche de dépendances de Portage. |
| 362 |
- Portage ne connaît pas DO_NOT_COMPILE et pense que l'ensemble du paquet |
| 363 |
- monolithique a été installé et peut satisfaire les dépendances d'autres |
| 364 |
- paquets. Cela peut amener ces autres paquets à ne pas pouvoir s'installer |
| 365 |
- ou ne pas pouvoir s'exécuter. |
| 366 |
- </li> |
| 367 |
- <li> |
| 368 |
- Il oblige l'utilisateur à connaître le nom et le sens de tous les différents |
| 369 |
- sous répertoires des modules KDE. Peu d'utilisateurs en connaissent le sens, |
| 370 |
- à moins d'être développeur KDE, vous avez peu de chances d'en faire partie. |
| 371 |
- Il y a peu de chances pour que vous utilisiez alors DO_NOT_COMPILE |
| 372 |
- correctement. |
| 373 |
- </li> |
| 374 |
- <li> |
| 375 |
- Les sous-répertoires de modules KDE peuvent avoir des dépendances entre |
| 376 |
- eux, nécessitent parfois un ordre précis de compilation, nécessitent la |
| 377 |
- présence d'un autre répertoire même s'il n'a pas besoin d'être installé, |
| 378 |
- etc. Nous avons passé beaucoup de temps sur les ebuilds séparés pour qu'ils |
| 379 |
- puissent fonctionner correctement dans ce sens. DO_NOT_COMPILE n'est pas un |
| 380 |
- outil assez fin pour obtenir des résultats aussi bons que les ebuilds |
| 381 |
- séparés, même si l'utilisateur a une connaissance suffisante pour pouvoir |
| 382 |
- le manipuler. La seule chose que cette variable vous permette de faire est |
| 383 |
- d'enlever de la compilation quelques applications. Il est pratiquement |
| 384 |
- impossible de l'utiliser pour installer deux ou trois applications à partir |
| 385 |
- de modules comme <c>kdebase</c> ou <c>kdepim</c>. |
| 386 |
- </li> |
| 387 |
- <li> |
| 388 |
- Si j'ai installé kmail hier et que je veux ajouter korn aujourd'hui, en |
| 389 |
- utilisant DO_NOT_COMPILE, il faudra recompiler kmail également. Cela |
| 390 |
- signifie que DO_NOT_COMPILE sera toujours plus lent que les ebuilds séparés. |
| 391 |
- </li> |
| 392 |
- <li> |
| 393 |
- DO_NOT_COMPILE ne peut pas être utilisé pour créer des paquets précompilés |
| 394 |
- (comme par exemple les GRP) contenant des applications individuelles de KDE. |
| 395 |
- </li> |
| 396 |
-</ul> |
| 397 |
- |
| 398 |
-</body> |
| 399 |
-</section> |
| 400 |
-<section> |
| 401 |
-<title>Est-ce que vous n'en demanderiez pas un peu trop aux mainteneurs KDE de |
| 402 |
-Gentoo ?</title> |
| 403 |
-<body> |
| 404 |
- |
| 405 |
-<p> |
| 406 |
-Curieusement, cette question est souvent revenue. Je suis content de voir que |
| 407 |
-les utilisateurs sont aussi prévenants à l'égard des mainteneurs. Laissez-moi |
| 408 |
-vous dire, pour l'occasion, que nous avons nous-même choisi la voie des ebuilds |
| 409 |
-séparés. Nous croyons que nous seront capables de maintenir les paquets avec la |
| 410 |
-même qualité qu'actuellement. Rien ne nous empêchera de faire les ebuilds |
| 411 |
-séparés. |
| 412 |
-</p> |
| 413 |
- |
| 414 |
-<p> |
| 415 |
-Pour être plus juste, je devrais ajouter que des mainteneurs d'autres |
| 416 |
-architectures se sont effectivement plaints de l'augmentation de charge de |
| 417 |
-travail, de tests et de gestion des mots-clefs sur autant d'ebuilds séparés. |
| 418 |
-Nous travaillons actuellement pour résoudre ce problème et c'est la raison |
| 419 |
-essentielle qui fait que les ebuilds monolithiques seront en fait toujours |
| 420 |
-disponibles pour KDE 3.5. |
| 421 |
-</p> |
| 422 |
- |
| 423 |
-</body> |
| 424 |
-</section> |
| 425 |
-<section> |
| 426 |
-<title>Allez-vous supprimer les ebuilds monolithiques ?</title> |
| 427 |
-<body> |
| 428 |
- |
| 429 |
-<p> |
| 430 |
-Nous essaierons de le faire. Cela dit, pour toutes les versions de KDE 3.x, nous |
| 431 |
-aurons à la fois des ebuilds monolithiques et séparés. |
| 432 |
-</p> |
| 433 |
- |
| 434 |
-<p> |
| 435 |
-Si vous préférez les ebuilds monolithiques aux séparés, merci de nous faire part |
| 436 |
-de <uri link="http://bugs.gentoo.org">vos raisons</uri>. |
| 437 |
-</p> |
| 438 |
- |
| 439 |
-</body> |
| 440 |
-</section> |
| 441 |
-<section> |
| 442 |
-<title>Il y a trop d'ebuilds ! Comment faire pour trouver celui dont j'ai |
| 443 |
-besoin ?</title> |
| 444 |
-<body> |
| 445 |
- |
| 446 |
-<p> |
| 447 |
-Tout d'abord, si vous savez que le paquet que vous recherchez vient avec kdebase |
| 448 |
-vous pouvez toujours faire un <c>emerge kdebase-meta</c>, qui vous permettra |
| 449 |
-de faire un peu la même chose que si vous installiez la version monolithique de |
| 450 |
-<c>kdebase</c>. |
| 451 |
-</p> |
| 452 |
- |
| 453 |
-<p> |
| 454 |
-Évidemment, vous pouvez utiliser tous les moyens habituels de recherche de |
| 455 |
-paquet. Trouveriez-vous votre ebuild si c'était une application Gnome ? Le |
| 456 |
-minimum est d'avoir le nom de l'application que vous recherchez. |
| 457 |
-</p> |
| 458 |
- |
| 459 |
-<p> |
| 460 |
-La situation pourrait peut-être être améliorée en ajoutant certains ebuilds de |
| 461 |
-type -meta. Ils sont à considérer comme des listes de dépendances, donc ça ne |
| 462 |
-nous coûte rien d'en créer. Mais nous n'avons pas encore décidé si nous le |
| 463 |
-ferons ou pas. De même, il serait bien que Portage puisse supporter certaines |
| 464 |
-fonctionnalités liées aux ebuilds -meta avant de se mettre à les utiliser de |
| 465 |
-manière excessive. |
| 466 |
-</p> |
| 467 |
- |
| 468 |
-</body> |
| 469 |
-</section> |
| 470 |
-<section> |
| 471 |
-<title>Comment puis-je lister/désinstaller tous les ebuilds séparés qui dérivent |
| 472 |
-d'un paquet donné ?</title> |
| 473 |
-<body> |
| 474 |
- |
| 475 |
-<p> |
| 476 |
-L'objectif ici est d'obtenir une liste de tous les ebuilds séparés de KDE |
| 477 |
-dérivant de, mettons, l'ebuild monolithique <c>kdebase</c>. Encore une fois, une |
| 478 |
-implémentation correcte (comme proposé dans la <uri |
| 479 |
-link="/proj/en/glep/glep-0021.html">GLEP 21</uri>) pourrait rendre cette |
| 480 |
-opération triviale. Mais, pour le moment, vous devrez jouer avec des détails |
| 481 |
-qui concernent l'implémentation des eclass KDE. Donc si vous les utilisez pour |
| 482 |
-un script qui n'est pas à usage privé, merci de nous le signaler. |
| 483 |
-</p> |
| 484 |
- |
| 485 |
-<p> |
| 486 |
-kde-functions.eclass définit des fonctions nommées get-parent-package() et |
| 487 |
-get-child-packages() qui font la traduction pour vous. Ces deux fonctions sont |
| 488 |
-un bon moyen d'obtenir la liste demandée à partir d'un ebuild ou d'un script |
| 489 |
-bash externe. Voici un exemple : |
| 490 |
-</p> |
| 491 |
- |
| 492 |
-<pre caption="Exemple d'utilisation des fonctions de kde-functions"> |
| 493 |
-$ <i>function die() { echo $@; }</i> |
| 494 |
-<comment># appelée pour afficher les erreurs</comment> |
| 495 |
-$ <i>source /usr/portage/eclass/kde-functions.eclass</i> |
| 496 |
-$ <i>get-parent-package konqueror</i> <comment># ne fonctionnera pas, vous |
| 497 |
-devez spécifier le nom complet</comment> |
| 498 |
-Package konqueror not found in KDE_DERIVATION_MAP, please report bug |
| 499 |
-<comment># erreur affichée</comment> |
| 500 |
-$ <i>get-parent-package kde-base/konqueror</i> <comment># nom complet</comment> |
| 501 |
-kde-base/kdebase <comment># résultat affiché</comment> |
| 502 |
-$ <i>get-child-packages kde-base/kdebase</i> |
| 503 |
-<comment>(Une longue liste de paquets s'affiche ci-dessous.)</comment> |
| 504 |
-</pre> |
| 505 |
- |
| 506 |
-<p> |
| 507 |
-Si votre script n'est pas en bash, vous pouvez récupérer dans |
| 508 |
-kde-functions.eclass la définition (sur plusieurs lignes) de la variable |
| 509 |
-KDE_DERIVATION_MAP que les fonctions citées plus haut utilisent. Cette variable |
| 510 |
-contient une liste de mots séparés par des espaces et chaque paire de mots |
| 511 |
-consécutifs permet de faire la correspondance entre un paquet parent et un |
| 512 |
-ebuild séparé qui hérite de celui-ci. |
| 513 |
+Ce document a été déplacé vers |
| 514 |
+<uri>/proj/fr/desktop/kde/kde-split-ebuilds.xml</uri>. |
| 515 |
</p> |
| 516 |
|
| 517 |
</body> |
Archives