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