1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
|
<?xml version='1.0' encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide link="/doc/it/gentoo-howto.xml">
<title>Gentoo Linux, HOWTO per gli sviluppatori</title>
<author title="Autore"><mail link="woodchip@gentoo.org">Donny Davies</mail></author>
<author title="Autore"><mail link="drobbins@gentoo.org">Daniel Robbins</mail></author>
<author title="Autore"><mail link="pete@gentoo.org">Peter Gavin</mail></author>
<author title="Autore"><mail link="karltk@gentoo.org">Karl Trygve Kalleberg</mail></author>
<author title="Autore"><!-- zhen@gentoo.org -->John P. Davis</author>
<author title="Autore"><mail link="vapier@gentoo.org">Mike Frysinger</mail></author>
<author title="Redattore"><mail link="peesh@gentoo.org">Jorge Paulo</mail></author>
<author title="Redattore"><mail link="swift@gentoo.org">Sven Vermeulen</mail></author>
<author title="Redattore"><mail link="klasikahl@gentoo.org">Zack Gilburd</mail></author>
<author title="Redattore"><mail link="bennyc@gentoo.org">Benny Chuang</mail></author>
<author title="Redattore"><mail link="erwin@gentoo.org">Erwin</mail></author>
<author title="Traduttore"><mail link="blaze@rootshell.be">Lino Gambella</mail></author>
<author title="Traduttore"><mail link="sogentoo@katamail.com">so</mail></author>
<author title="Traduttore" >
Team Italiano
</author>
<abstract>Questo documento descrive il Portage system di Gentoo Linux, come
creare nuovi pacchetti per Gentoo e dà un certo standard per gli sviluppatori di Gentoo. E`
costantemente sotto modifiche e viene aggiornato e cambiato frequentemente. Non è completo.
Dovreste usarlo <e>sempre</e> insieme alle manpages fornite da portage (specialmente ebuild(5))
e alla <uri link="http://www.gentoo.org/doc/it/policy.xml">Politica di Sviluppo di Gentoo Linux</uri>.
</abstract>
<version>1.4.7</version>
<date>12 Febbraio 2004</date>
<chapter>
<title>Il Portage tree</title>
<section>
<title>Introduzione</title>
<body><p>Il portage tree si trova tipicamente in <path>/usr/portage</path> ed è
organizzato in una struttura gerarchica consistente in directory categoria,
seguite da directory specifiche per ogni pacchetto. Ecco un esempio; potete trovare
il file <path>util-linux-2.11y.ebuild</path> nella directory <path>/usr/portage/sys-apps/util-linux</path>.
Possono esserci anche altre versioni di <c>util-linux</c> oltre che <path>util-linux-2.11y.ebuild</path>.
Ciò è dovuto al fatto che <e>tutti gli ebuilds per un particolare pacchetto (indipendentemente dalla
versione)</e>, condividono la stessa directory <path>miacategoria/miopacchetto</path> in <path>/usr/portage</path>.
</p>
</body>
</section>
<section>
<title>Controllare il Portage Tree dal CVS</title>
<body>
<p>Se il sistema CVS non vi è familiare, per favore controllate il
<uri link="http://www.gentoo.org/doc/en/cvs-tutorial.xml" >CVS Tutorial</uri>
per maggiori informazioni. </p>
<p>Il Portage tree può essere trovato nel pacchetto <c>gentoo-x86</c> del Gentoo Linux tree.
Per controllare il pacchetto (circa 350 megabytes) dovete prima settare CVS tramite la guida
precedente, poi controllare il tree <c>gentoo-x86</c>.</p>
</body>
</section>
<section>
<title>Cosa (non) mettere nel Portage tree</title>
<body>
<p>Prima di scrivere gli ebuild, controllate <uri link="http://bugs.gentoo.org" >bugs.gentoo.org</uri>
per vedere che non ci sia già un'ebuild corrispondente ma non ancora messo nel portage tree.
Andate su <uri link="http://bugs.gentoo.org" >bugs.gentoo.org</uri>, scegliete query, scegliete <e>Gentoo Linux</e>
come prodotto e come componente <e>ebuilds</e>, nel campo ricerca mettete il nome dell'ebuild e come status
scegliete NEW, ASSIGNED REOPENED and RESOLVED (RESOLVED è importante), dopo mandate la query. Quelli che sono pigri,
clicchino <uri link="http://bugs.gentoo.org/query.cgi?product=Gentoo%20Linux&component=Ebuilds&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED">qui</uri>. </p>
<p>Generalmente, il Portage tree deve essere usato solo per contenere i files <path>.ebuild</path>
insieme ad altri file piccoli, come patch o esempi di configurazione. Questi tipi di files devono
andare nella directory <path>/usr/portage/categoria/pacchetto/files</path> per tenere pulita la
directory <path>categoria/pacchetto</path>. Le eccezioni a questa regola sono per grandi patch che
dovrebbero essere messe nei Gentoo mirrors in modo che la gente non sprechi eccessivamente la
larghezza di banda e lo spazio dell'hard drive. Non è una buona idea da parte degli sviluppatori
aggiungere file binari (non-ASCII) al CVS. Comunque, se è necessario (ad esempio, se dovete aggiungere
una piccola PNG per qualsiasi ragione), accertatevi di aggiungerla a CVS usando l'opzione <c>-kb</c>
nel modo seguente:</p>
<pre>
# <i>cvs add -kb miafoto.png</i>
</pre>
<p>L'opzione <c>-kb</c> dice a CVS che <path>miafoto.png</path> è un file binario e
deve essere trattato in maniera speciale. Per esempio, fondere le differenze di due versioni
diverse di questo file, non è possibile, per ovvie ragioni. Così parlando di fusioni, tutte le
patch che aggiungete al Portage devono necessariamente <e>non</e> essere compresse. Questo permette
a CVS di fondere i cambiamenti e informare correttamente gli sviluppatori se dovessero verificarsi
conflitti.</p>
<p>Ricordate, i pacchetti che create devono essere <e>pronti</e> e <e>fuori dal box</e> per
gli utenti quando vengono marcati stabili. Assicuratevi di avere un buon insieme di settaggi
di default che soddisfino la maggior parte dei sistemi e degli utenti che utilizzeranno
il vostro pacchetto. Se il vostro pacchetto non va, e siete poco sicuri su come farlo funzionare,
controllate altre distribuzioni che hanno già forgiato le loro versioni del pacchetto. Potete
controllare <uri link="http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/SPECS/" >Mandrake</uri> o
<uri link="http://www.debian.org/distrib/packages" >Debian</uri> per qualche esempio.</p>
<p>
Ricontrollate l'ebuild e leggete il documento <uri link="http://www.gentoo.org/doc/en/ebuild-mistakes.xml">Common Gentoo Ebuild Mistakes</uri>.
</p>
<p>Quando eseguono il commit a CVS, tutti gli sviluppatori devono usare <c>repoman commit</c> invece di
<c>cvs commit</c> per mandare i loro ebuilds. Prima di inviare, per favore fate girare <c>repoman full</c>
per essere sicuri di non aver dimenticato qualcosa.</p>
</body>
</section>
<section>
<title>CVS Commit Policy</title>
<body>
<ul>
<li>Dovete sempre eseguire <c>repoman scan</c> prima del commit.</li>
<li>Per favore eseguite <c>repoman full</c> prima del commit.</li>
<li>Prima di eseguire il commit eseguite sempre il test su <path>package.mask</path>, deve andar bene facendo <c>emerge --pretend miopacchetto</c> per assicurarvi
che non ci siano conflitti.</li>
<li>Aggiornate il <path>ChangeLog</path> prima del commit.</li>
<li>Prima del pacchetto, fate il commit del file <path>package.mask</path>, in caso ci siano conflitti sul file.</li>
<li>Fate sempre atomic commit; se si esegue il commit di un pacchetto con una nuova licenza, o che è "masked",
prima eseguite il commit del <path>package.mask</path> revisionato, poi l'ebuild, il <path>ChangeLog</path> e la licenza, tutto in una volta, sempre che non vogliate
rovinare l'installazione degli utenti. </li>
</ul>
</body>
</section>
<section>
<title>La directory Files
</title>
<body>
<p>Come indicato prima, sotto ogni subdirectory di ogni pacchetto c'è una directory <path>files/</path>.
Ogni patch, file di configurazione o altri files che il vostro pacchetto richiede vanno messi
in questa directory. Potete considerare di nominare le patch che create solo per indurre il pacchetto
a costruirsi con un nome specifico per la versione, come <path>miopacchetto-1.0-gentoo.diff</path>.
Si noti che l'estensione <path>gentoo</path> informa gli utenti che la patch è stata creata
da noi, gli sviluppatori Gentoo, non è stata assolutamente presa da mailing lists o cose simili. Ancora,
non dovete comprimere i files diff perchè CVS non supporta i file binari.
</p>
<p>Considerate l'aggiunta di un prefisso o suffiso come <path>miopacchetto-1.0</path> in coda a ogni
file che mettete nella directory <path>files/</path>, così che i files usati per ogni
versione individuale degli ebuild del pacchetto siano distinguibili dagli altri, così
che i cambiamenti fra le varie revisioni siano visibili. Questa è generalmente una buona
idea :). Potete anche usare suffissi differenti se volete maggior precisione.
</p>
<p>Se avete vari files che devono andare nella directory <path>files/</path>, considerate la creazione di subdirectory
come ad esempio <path>files/miopacchetto-1.0/</path> e mettete i file nella sua appropriata subdir.
Se usate questo metodo, non avrete bisogno di aggiungere suffissi ai nomi dei files nella directory files.
Questo metodo è spesso più conveniente.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Scripts ebuild</title>
<section>
<title>Introduzione</title>
<body>
<p>Gli script ebuild sono la base dell'intero sistema di portage. Essi contengono
tutte le informazioni necessarie allo scaricamento, scompattamento, alla compilazione
e all'installazione dei sorgenti, così come servono ad eseguire funzioni di configurazione
pre o post installazione. Mentre molto del Portage è scritto in Python, gli ebuilds sono
scritti in bash, visto che bash permette di chiamare comandi come si fa da linea di comando.
Una delle caratterstiche più importanti degli scripts ebuild è l'avere i comandi analoghi a
quelli che si scriverebbero da riga di comando se si installasse il pacchetto manualmente. A questo scopo, usare la sintassi bash è
un'ottima cosa.
</p>
<p>
Gli scripts ebuild vengono interpretati dai comandi <c>ebuild</c> ed <c>emerge</c>.
Il comando <c>ebuild</c> è un tool di costruzione a basso livello. Può
costruire e installare un singolo ebuild. Controlla se le dipendenze sono
soddisfatte, non tenta però di risolverle automaticamente. Dall'altra parte, <c>emerge</c> è un motore
ad alto livello per <c>ebuild</c> e ha l'abilità di auto-installare le dipendenze se necessarie,
eseguire <e>pretend</e> così che l'utente possa vedere quali ebuild <e>saranno</e> installati, e molto
di più. In generale, <c>emerge</c> salta <c>ebuild</c> tranne che in una area. Con <c>ebuild</c>, potete eseguire le tappe di varie parti dell'installazione di un pacchetto
(scaricamento, scompattamento, compilazione, installazione e merging) una per volta. Per gli
sviluppatori questo tool è di valore inestimabile, perchè permette di isolare i problemi
degli ebuilds a una specifica porzione di un processo ebuild.
</p>
</body>
</section>
<section>
<title>Dare il nome ai file ebuild</title>
<body>
<p>Il nome dei file ebuild, consiste in quattro sezioni logiche:</p>
<p>La prima sezione è il nome del pacchetto, che dovrà contenere solo
lettere minuscole, cifre 0-9 e un certo numero di caratteri '-' o '_'.
Ad esempio: <c>util-linux</c>, <c>sysklogd</c>, <c>mod_php</c>, e <c>glibc</c>.</p>
<p>La seconda sezione è la versione del pacchetto, che dovrà essere normalmente
la stessa dei sorgenti del tarball principale. La versione viene normalmente formata
da 2 o 3 numeri separati da punti, come <c>1.2</c> o <c>4.5.2</c> (comunque sequenze
molto lunghe di numeri <e>sono</e> supportate), e può avere una lettera singola che segue
l'ultima cifra, esempi: <c>1.4b</c> o <c>2.6h</c>. La versione del pacchetto viene attaccata
al suo nome con un trattino, ad esempio: <c>foo-1.0</c>, <c>bar-2.4.6</c> eccetera.
</p>
<impo>Se state pensando di usare una lettera nella versione del vostro pacchetto, ricordatevi
che le trailing letter <e>non</e> si possono usare per indicare lo status alpha o beta per un pacchetto,
da quando alpha e beta sono <e>prereleases</e> e le revisioni sono <e>newer versions</e>. Questa
è un'importante distinzione perchè portage usa il numero di versione dell'ebuild per determinare
se è più nuova o più vecchia degli altri pacchetti con la stessa categoria e lo stesso nome.
Questo numero di versione è molto importante e rappresenta la versione del pacchetto, così
Portage può eseguire appropriatamente il controllo delle dipendenze.</impo>
<p>La terza (opzionale) sezione contiene uno speciale suffisso, può essere <c>_alpha</c>, <c>_beta</c>,
<c>_pre</c>, <c>_rc</c>, o <c>_p</c>. Ognuno di questi suffissi può essere seguito da un numero, esempio: <c>linux-2.4.0_pre10</c>;
Assumendo che le parti della versione siano identiche, un pacchetto <c>_alpha</c> è più vecchio di un <c>_beta</c>,
come <c>_beta</c> è più vecchio di un <c>_pre</c> e un <c>pre</c> è più vecchio di un <c>_rc</c>, e <c>_rc</c> è più vecchio di un <c>_p</c>. Questa sezione è significativa per riflettere solo le versioni upstream.
</p>
<note>Un pacchetto <c>_rc</c> è più vecchio di un pacchetto senza un suffisso underscore (es. <c>linux-2.4.0</c>), e
<c>linux-2.4.0</c> è più vecchio di un pacchetto con un suffisso a lettera singola, es. <c>linux-2.4.0b</c>. Come vi
potete aspettare, il pacchetto <c>linux-2.4.0b</c> viene considerato più vecchio di <c>linux-2.4.0c</c>. Ancora questa
informazione di versione è importante, Portage la usa internamente per determinare quale pacchetto o ebuild è più nuovo
di un altro della stessa categoria e nome.</note>
<p>La quarta (opzionale) sezione del nome di un pacchetto è la specifica di <e>revisione</e> Gentoo Linux, specificata
da <c>-r#</c> dove <c>#</c> è un numero intero, es. <c>pacchetto-4.5.3-r3</c>. Questo numero di revisione è indipendente
dalla versione dei sorgenti ed è usato per informare le persone che una versione nuova e particolare del pacchetto è stata
rilasciata da Gentoo.</p>
<p>Se fate miglioramenti a un ebuild esistente, potete copiarlo in un nuovo file con il numero
di revisione incrementato di 1. Le release iniziali normalmente non hanno numero di versione, es. <path>pacchetto-4.5.3</path>, il loro
numero di revisione viene considerato da Portage come zero. Ciò significa che il conteggio va nel modo seguente: <c>1.0</c> (versione
iniziale), <c>1.0-r1</c>, <c>1.0-r2</c> ecc. Ricordate <e>sempre</e> di menzionare i cambiamenti nel <path>ChangeLog</path>, potete andare in guai
seri se non lo fate, il vostro accesso CVS potrebbe essere revocato.</p>
<p>Ovviamente si ha la <e>quinta</e> sezione del nome di un ebuild -- l'estensione <c>.ebuild</c>.
</p>
</body>
</section>
<section>
<title>Contenuti di un file <e>ebuild</e></title>
<body>
<note>
Questa sezione è una introduzione agli ebuilds. Per la lista completa di ogni cosa possibile in un ebuild, c'è una manpage che riferisce sulla disposizione interna, variabili, e funzioni in uno script ebuild: <c>man 5 ebuild</c>
</note>
<p><b>Settaggi di variabili:</b></p>
<p>La prima parte di ogni ebuild è formata da un certo numero di dichiarazione di variabili. Le variabili risiedono sotto 3 categorie (e sono segnate sotto con questi numeri):
</p>
<ul>
<li>READ: variabili che potete utilizzare ma <e>mai settare</e></li>
<li>MUST: variabili che <e>dovete sempre settare</e></li>
<li>OPT: variabili che dovreste settare</li>
</ul>
<table>
<tr>
<th>Variabile</th>
<th>Uso</th>
<th>Descrizione</th>
</tr>
<tr>
<ti><c>P</c></ti>
<ti>READ</ti>
<ti>Il nome e la versione del pacchetto.</ti>
</tr>
<tr>
<ti><c>PN</c></ti>
<ti>READ</ti>
<ti>Il nome del pacchetto.</ti>
</tr>
<tr>
<ti><c>PV</c></ti>
<ti>READ</ti>
<ti>La versione del pacchetto.</ti>
</tr>
<tr>
<ti><c>PR</c></ti>
<ti>READ</ti>
<ti> contiene il numero di revisione o <c>r0</c> se non esiste in numero di revisione.</ti>
</tr>
<tr>
<ti><c>PVR</c></ti>
<ti>READ</ti>
<ti>Contiene il numero della versione con la revisione.</ti>
</tr>
<tr>
<ti><c>PF</c></ti>
<ti>READ</ti>
<ti>Contiene il nome completo del pacchetto <c>${PN}-${PV}-${PR}</c>.</ti>
</tr>
<tr>
<ti><c>A</c></ti>
<ti>READ</ti>
<ti>
Spazio nella lista delimitata di filenames in <c>SRC_URI</c>. Non contiene il percorso dell'URL, solo il filename.
</ti>
</tr>
<tr>
<ti><c>WORKDIR</c></ti>
<ti>READ</ti>
<ti>
Base del build root per l'ebuild. Niente dovrebbe essere sviluppato fuori da questa directory.
</ti>
</tr>
<tr>
<ti><c>FILESDIR</c></ti>
<ti>READ</ti>
<ti>
Contiene il percorso al <path>files</path> sub folder nella posizione specifica del pacchetto nel portage tree. Non modificare questa variabile.
</ti>
</tr>
<tr>
<ti><c>S</c></ti>
<ti>OPT</ti>
<ti>
La directory sorgente per il vostro pacchetto; comunemente <c>${WORKDIR}/${P}</c>. Portage si stabilizzerà a questo valore in modo che non dobbiate regolarlo!
</ti>
</tr>
<tr>
<ti><c>T</c></ti>
<ti>READ</ti>
<ti>
La directory temporanea per il vostro pacchetto. E' usata come una directory virtuale <path>/tmp</path> mentre elaborate l'ebuild.
</ti>
</tr>
<tr>
<ti><c>D</c></ti>
<ti>READ</ti>
<ti>
La directory root in cui il pacchetto è installato, trattata come virtuale <path>/</path>.
</ti>
</tr>
<tr>
<ti><c>SLOT</c></ti>
<ti>MUST</ti>
<ti>
Portage supporta le varie versioni dello stesso pacchetto installato. Se volete, avendo installati sia GCC 2.95 che GCC 3.2, potete specificare lo <c>SLOT</c> in ogni ebuild. Qui possiamo settare lo <c>SLOT</c> di GCC 2.95 a <c>2</c> mentre possiamo settare lo <c>SLOT</c> di GCC 3.2 a <c>3</c>.
<note>
Usando <c>0</c> come valore di <c>SLOT</c> significa che quel pacchetto ha 1 solo <c>SLOT</c> da settare (in altre parole, quel pacchetto non è SLOTable).
</note>
</ti>
</tr>
<tr>
<ti><c>LICENSE</c></ti>
<ti>MUST</ti>
<ti>
Questa variabile indica sotto che licenza è il programma, es. GPL-2, BSD, eccetera. Questo campo deve essere configurato con una licenza valida (ogni licenza si trova in <path>/usr/portage/license/</path>). Se la licenza non esiste qua, deve essere aggiunta prima che l'ebuild sia aggiunto al portage tree.
</ti>
</tr>
<tr>
<ti><c>KEYWORDS</c></ti>
<ti>MUST</ti>
<ti>
Questa variabile supporta una serie di funzioni diverse. Prima di tutto specifica l'architettura alla quale si rifà l'ebuild. Queste keywords includono: <e>x86, ppc, sparc, mips, alpha, arm, hppa, amd64, ia64</e>. Ovviamente dovete settare questa variabile in modo che indichi l'architettura per la macchina destinataria. Portage non permette a una macchina x86 di costruire altro se non pacchetti x86, come specificato nella variabile <c>KEYWORDS</c>. I pacchetti che non sono di una architettura nativa sono mascherati automaticamente da Portage. Se la flag <c>KEYWORDS</c> è preceduta da <e>~</e>, significa che l'ebuild funziona, ma necessita di essere testato in molte parti prima di essere spostato a stabile con la data keyword. Se la flag <c>KEYWORDS</c> è preceduta da <e>-</e>, allora il pacchetto non funzionerà con la data keyword. Se non c'è niente nella flag <c>KEYWORDS</c>, il pacchetto viene considerato stabile. Potete eseguire l'installazione di questi tipi diversi di pacchetti attraverso la variabile <c>ACCEPT_KEYWORDS</c> in <path>make.conf</path>.
</ti>
</tr>
<tr>
<ti><c>DESCRIPTION</c></ti>
<ti>MUST</ti>
<ti>Una <e>breve</e> descrizione di una riga del vostro pacchetto.</ti>
</tr>
<tr>
<ti><c>SRC_URI</c></ti>
<ti>MUST</ti>
<ti>
Gli URL per ogni sorgente del vostro pacchetto, separati da spazi bianchi. Normalmente il primo è qualcosa come "ftp://ftp.company.com/pub/somepackage/${P}.tar.bz2"
</ti>
</tr>
<tr>
<ti><c>HOMEPAGE</c></ti>
<ti>MUST</ti>
<ti>
La homepage del pacchetto. Se non siete capaci di individuarne una ufficiale, cercate di fornire un link da <uri
link="http://freshmeat.net/">freshmeat.net</uri> o da un simile sito di ricerca pacchetti.
</ti>
</tr>
<tr>
<ti><c>IUSE</c></ti>
<ti>MUST</ti>
<ti>
Indica quale variabile <c>USE</c> il vostro pacchetto utilizza. Ricordare che le <c>KEYWORDS</c> non siano elencate qui!
</ti>
</tr>
<tr>
<ti><c>DEPEND</c></ti>
<ti>OPT</ti>
<ti>
Le dipendenze di costruzione del pacchetto sono elencate qui. Vedete la sezione <uri link="#doc_chap5">Dipendenze di pacchetti</uri> per maggiori dettagli sull'appropriata sintassi.
</ti>
</tr>
<tr>
<ti><c>RDEPEND</c></ti>
<ti>OPT</ti>
<ti>
Le dipendenze di runtime del pacchetto sono elencate qui. Di nuovo, vedete <uri link="#doc_chap5">Dipendenze di pacchetti</uri> per maggiori dettagli.
</ti>
</tr>
</table>
<p><b>Funzioni ebuild</b></p>
<p>C'è un numero di funzioni diverse che potete definire in un file ebuild che controllano il processo di costruzione e installazione del vostro pacchetto.</p>
<table>
<tr>
<ti><c>pkg_setup</c></ti>
<ti>
Usate questa funzione per eseguire vari tasks prerequisiti dal pacchetto. Questo include l'aggiunta di account di
sistema o il controllo di un file di configurazione esistente.
</ti>
</tr>
<tr>
<ti><c>pkg_nofetch</c></ti>
<ti>
Informate l'utente sulle azioni richieste se per qulache ragione (così come le licenze) i sorgenti potrebbero non essere scaricabili automaticamente. Usate questo insieme con <c>RESTRICT="fetch"</c>. Voi soltanto visualizzerete i messaggi in questa funzione, mai chiamare <c>die</c>.
</ti>
</tr>
<tr>
<ti><c>src_unpack</c></ti>
<ti>
Usate questa funzione per scompattare i sorgenti, applicare patch, ed eseguire programmi di aiuto come gli autotools. Di default,
scompatta i pacchetti elencati in <c>A</c>. La directory di partenza è definita da <c>WORKDIR</c>.
</ti>
</tr>
<tr>
<ti><c>src_compile</c></ti>
<ti>
Usate questa funzione per configurare e costruire il pacchetto. La directory di partenza è <c>S</c>.
</ti>
</tr>
<tr>
<ti><c>src_install</c></ti>
<ti>
Usate questa funzione per installare il pacchetto in un'immagine in <c>D</c>. Se il vostro pacchetto usa automake,
potete fare questo semplicemente con <c>make DESTDIR=${D} install</c>. <e>Assicuratevi che il vostro pacchetto installi i suoi file utilizzando <c>D</c> come root!</e> La directory di partenza è <c>S</c>.
</ti>
</tr>
<tr>
<ti><c>pkg_preinst</c></ti>
<ti>
I comandi vengono eseguiti <e>prima di eseguire il merging</e> dell'immagine del pacchetto nel filesystem.
</ti>
</tr>
<tr>
<ti><c>pkg_postinst</c></ti>
<ti>
I comandi vengono eseguiti <e>dopo il merge</e> dell'immagine del pacchetto nel filesystem.
</ti>
</tr>
<tr>
<ti><c>pkg_prerm</c></ti>
<ti>
I comandi vengono eseguiti <e>prima dell'unmerge</e> dell'immagine del pacchetto dal filesystem.
</ti>
</tr>
<tr>
<ti><c>pkg_postrm</c></ti>
<ti>
I comandi vengono eseguiti <e>dopo l'unmerge</e> dell'immagine del pacchetto dal filesystem.
</ti>
</tr>
<tr>
<ti><c>pkg_config</c></ti>
<ti>
Potete usare questa funzione per configurare inizialmente il pacchetto dopo che è stato installato. Tutti i percorsi in
questa funzione devono avere il prefisso <c>ROOT</c>. Questa funzione viene eseguita <e>solo</e> e quando l'utente esegue: <c>ebuild /var/db/pkg/${CATEGORY}/${PF}/${PF}.ebuild config</c>.
</ti>
</tr>
</table>
<p><b>Funzioni di assistenza</b></p>
<p>
Potete inoltre usare le seguenti funzioni di assistenza nei vostri ebuilds.
</p>
<table>
<tr>
<ti><c>use</c></ti>
<ti>
Controlla se una o più flag use date sono definite. Se così, la funzione riprenderà le flag che esistono in <c>USE</c>. Per controllare l'esistenza di una flag use, potete usare <c>[ `use foobar` ]</c>.
</ti>
</tr>
<tr>
<ti><c>has_version</c></ti>
<ti>
Ritorna 1 se il sistema ha la versione richiesta di un certo pacchetto. Per esempio <c>has_version >=glibc-2.3.0</c>.
</ti>
</tr>
<tr>
<ti><c>best_version</c></ti>
<ti>
Ritorna la <path>categoria/versione-pacchetto</path> del <path>categoria/pacchetto</path> richiesto. Per esempio <c>best_version x11-libs/gtk+extra</c>.
</ti>
</tr>
<tr>
<ti><c>use_with</c></ti>
<ti>
Questa funzione controlla se una flag use è stata definita e di conseguenza ritorna "--with-foobar" o "--without-foobar". Se usate un solo argomento, qull'argomento è sia flag use sia con/senza stringa. Altrimenti il primo argomento è la flag use e il secondo argomento è con/senza stringa. Per esempio <c>use_with truetype freetype</c> riprenderà "--with-freetype" se truetype è in <c>USE</c>.
</ti>
</tr>
<tr>
<ti><c>use_enable</c></ti>
<ti>
Uguale a <c>use_with</c>, ma di conseguenza ritorna "--enable-foobar" o "--disable-foobar".
</ti>
</tr>
<tr>
<ti><c>check_KV</c></ti>
<ti>
Controlla se Portage conosce la versione del kernel. Se non la conosce, visualizza un errore e si chiude. Se avete bisogno della versione del kernel nel vostro script, usate la variabile <c>KV</c> che è automaticamente definita da Portage. Su un sistema che ha gentoo-sources-2.4.20-r6, <c>KV</c> avrebbe il valore "2.4.20".
</ti>
</tr>
<tr>
<ti><c>keepdir</c></ti>
<ti>
Crea (se necessario) un file <path>.keep</path> nella directory data così che non si auto-pulisca. Non create <e>mai</e> voi stessi un file <path>.keep</path>. Se portage cambia come <c>keepdir</c> funziona, allora la vostra crezione del file romperà il pacchetto.
</ti>
</tr>
<tr>
<ti><c>econf</c></ti>
<ti>
Mette <c>./configure</c> con il necessario cambio di percorso (prefix, host, mandir, infodir, datadir, sysconfdir, localstatedir). Facoltativamente potete passare gli atgomenti extra a <c>./configure</c> specificandoli quando chiamate <c>econf</c>, e/o quando regolate la variabile di ambiente <c>EXTRA_ECONF</c>. Opzioni passate a configure hanno la precedenza in ordine inverso rispetto a come sono state date. In altre parole, il primo argomento sarà sempre sovrascritto dall'ultimo.
</ti>
</tr>
<tr>
<ti><c>einstall</c></ti>
<ti>
Mette <c>make install</c> con il necessario cambio di percorso (prefix, datadir, mandir, infodir, datadir, sysconfdir, localstatedir). Di nuovo, potete passare argomenti extra al comando make specificandoli quando chiamate <c>einstall</c>. Per favore notate che il modo preferito di installare un pacchetto è con il comando <c>make install DESTDIR=${D}</c> e non con <c>einstall</c>. Questo comando è soltanto una maniera per sovrascrivere i make file rotti.
</ti>
</tr>
<tr>
<ti><c>die</c></ti>
<ti>
Causa la chiusura del processo corrente. Avviserà l'utente usando il dato argomento come ragione. Non trascurate di passare un messaggio a <c>die</c> se avete più di una chiamata ad esso in una singola funzione. E' più duro rintracciare un guasto se non siete sicuri <c>dove</c> il pacchetto è rotto.
</ti>
</tr>
<tr>
<ti><c>einfo</c></ti>
<ti>
Informa l'utente su qualcosa di importante. L'argomento dato a <c>einfo</c> è il messaggio che l'utente vedrà. Non usate <c>einfo</c> per visualizzare banner come "*************************************". Il fatto che state usando <c>einfo</c> è abbastanza per ottenere l'attenzione dell'utente.
</ti>
</tr>
</table>
</body>
</section>
<section>
<title>Regole di scrittura di un file ebuild</title>
<body>
<p>Visto che i file ebuild sono semplicemente degli shell script, potete usare il mode shell-script nel vostro editor. Dovete
usare una certa indentazione, usare solo caratteri di tabulazione -- <e>non spazi</e>. Assicuratevi di configurare il vostro editor in modo
che metta 4 spazi per ogni tab. Ancora assicuratevi di usare le parentesi attorno alle variabili d'ambiente; es. <c>${P}</c> invece
di <c>$P</c>.</p>
<p>Le linee lunghe vengono spezzate con ' \', così:</p>
<pre>
./configure \
--prefix=/usr || die "configure failed"
</pre>
<p>Per altri dettagli, controllate <path>skel.ebuild</path> (abitualmente sotto <path>/usr/portage</path>).</p>
<p>Se state usando Vim, potete mettere il seguente codice alla fine del vostro file .vimrc per essere sicuri
di avere i settaggi giusti quando editate qualcosa di relativo a Gentoo.
</p>
<pre>
if (getcwd() =~ 'gentoo-x86\|gentoo-src\|portage')
set tabstop=4 shiftwidth=4 noexpandtab
endif
</pre>
<p>Se state usando Emacs, potete mettere il seguente codice alla fine del vostro .emacsrc (per GNU Emacs) o init.el (per XEmacs) per
essere sicuri di avere i settaggi giusti quando editate qualcosa di relativo a Gentoo.</p>
<pre>
(defun ebuild-mode ()
(shell-script-mode)
(sh-set-shell "bash")
(make-local-variable 'tab-width)
(setq tab-width 4))
(setq auto-mode-alist (cons '("\\.ebuild\\'" . ebuild-mode) auto-mode-alist))
(setq auto-mode-alist (cons '("\\.eclass\\'" . ebuild-mode) auto-mode-alist))
</pre>
<p>
Se state usando nano, siete fortunati! Editate <path>/etc/nanorc</path> e scommentate la sezione riferente all'ebuild.
</p>
</body>
</section>
<section>
<title>Variabili <c>USE</c></title>
<body>
<p>Lo scopo delle variabili USE è permettervi di configurare Portage per abilitare
o disabilitare globalmente e automaticamente certe <e>opzioni in tempo di compilazione</e>.
Eccovi un esempio. Diciamo che siete fan di GNOME, e vi piacerebbe avere ogni ebuild con
il supporto per GNOME. In questo caso dovete aggiungere <c>gnome</c> alla variabile <c>USE</c> in
<path>/etc/make.conf</path> e allora Portage automaticamente aggiungerà ogni supporto opzionale
GNOME ai pacchetti, se disponibile. Se invece non volete il supporto per GNOME, semplicemente modificate
<path>/etc/make.conf</path> e assicuratevi che <c>gnome</c> <e>non</e> sia indicato nella variabile <c>USE</c>.
Gentoo Linux ha un numero grandissimo di opzioni USE, per permettervi di configurare il sistema come meglio
credete.
</p>
<note>Se disattivate una variabile USE (ad esempio togliendo <c>gnome</c> da <c>USE</c>), ciò istruirà solo Portage
a togliere il supporto <e>opzionale</e> per GNOME. Comunque se eseguite <c>emerge</c> su un ebuild che <e>richiede</e> GNOME,
il pacchetto avrà ovviamente il supporto per GNOME attivo, come vi potete aspettare. Ciò significa anche che GNOME verrà
installato automaticamente (come dipendenza) se non è stato già fatto prima. E` sempre una buona idea eseguire un <c>emerge --pretend</c>
prima di fare un "reale" <c>emerge</c>; così sapete a cosa andate incontro!</note>
<p>Nei vostri ebuild, potete controllare se una variabile USE è settata usando
il comando <c>use <variable></c>. Il comando <c>use</c> stampa il nome di ogni <c><variabile></c> presente in <c>USE</c>. Potete usarla normalmente come segue:</p>
<pre>
if [ `use X` ] ; then
commands specific to X
fi
</pre>
<p>Le variabili USE possono anche essere usate per settare dipendenze. Per esempio, potete voler installare un pacchetto
solo se quella determinata variabile USE è dichiarata. Ciò si fa usando la sintassi <c>variable? ( categoria/pacchetto)</c> nella
variabile <c>DEPEND</c> del vostro ebuild. In questo esempio <c>categoria/pacchetto</c> verrà richiesto solo se la <c>variabile</c> è presente
in <c>USE</c>. E' anche possibile specificare quale dipendenza dovrebbe essere usata se qualche useflag è settata, e quale dipendenza usare se <e>non</e> è settata: <c>variable? (categoria/pacchetto) : ( altracategoria/altropacchetto )</c>. In questo caso, se la <c>variabile</c> non è settata, <c>altracategoria/altropacchetto</c> è usato invece di <c>categoria/pacchetto</c>. Infine potete specificare una dipendenza nel caso in cui una certa variabile <e>non</e> è settata. E fissate la variabile con "!", come: <c>!variable? ( categoria/pacchetto )</c>. Assicuratevi che i vostri ebuild utilizzino questa sintassi e non gli ifs di Bash. Le espressioni condizionali di Bash possono
interferire con le funzioni di Portage, e l'uso dei comandi Bash può rovinare il vostro ebuild.
</p>
<p>C'è qui un suggerimento importante su come usare <c>USE</c>. Per la maggior parte delle volte,
un pacchetto avrà uno script <c>./configure</c> utilizzato per eseguire i passi di configurazione.
Generalmente, se il vostro ebuild usa <c>./configure</c>, ogni funzionalità opzionale a tempo di compilazione
dovrà essere attivata o disattivata passando gli argomenti appropriati al comando <c>./configure</c>.
C'è qua il modo migliore per far questo:
</p>
<pre>
DEPEND="X? ( >=x11-base/xfree-4.3 )
mysql? ( >=dev-db/mysql-3.23.49 )
apache2? ( >=net-www/apache-2 ) : ( =net-www/apache-1.* )"
src_compile() {
econf \
`use_enable X x11` \
`use_enable mysql` \
|| die "configure failed"
emake || die "emake failed"
}
</pre>
<p>
Questo approccio ha un risultato molto piacevole. Non dobbiamo spaventarci su cosa è il setting di default per mysql o per X (abilitato/disabilitato), noi esplicitamente diciamo a <c>econf</c> cosa vogliamo fare basandoci sulla variabile <c>USE</c>. Non accennarlo è abbastanza chiaro in termini di leggibilità :).
</p>
<p>Per vedere una tabella in continuo aggiornamento dei settaggi USE, andate
<uri link="http://www.gentoo.org/dyn/use-index.xml">qui</uri>. </p>
</body>
</section>
</chapter>
<chapter>
<title>Locazione nel filesystem</title>
<section>
<title>Introduzione a FHS</title>
<body>
<p>Gli standard del layout del filesystem usati in Gentoo Linux, seguono FHS,
abbreviazione di <e>Filesystem Hierarchy Standard</e> (Gerarchia di filesystem standard).
Una descrizione semplificata dello standard viene data qui, per una descrizione specifica
andate all'url: <uri>http://www.pathname.com/fhs/</uri>.</p>
<note> Il percorso <path>/opt</path> è indirizzato nella sezione 3.12 di FHS. La sezione 4.4
tratta del percorso <path>/usr/X11R6</path>. KDE e GNOME
non sono indirizzati specificatamente e non sono menzionati nella versione corrente
di FHS.</note>
</body>
</section>
<section>
<title>Come mettere i pacchetti nel filesystem</title>
<body>
<p>Abitualmente, se il pacchetto usa autoconf e automake, l'installazione
di default darà una destinazione quasi sempre corretta, salvo eccezioni:</p>
<ul>
<li>Se state installando un programma in <path>/bin</path>, <path>/sbin</path>,
<path>/usr/bin</path> o <path>/usr/sbin</path>, la sua manpage deve essere
installata in <path>/usr/share/man</path>. Ciò può essere eseguito specificando
<c>./configure --mandir=/usr/share/man</c> nell'ebuild.</li>
<li>I file GNU info, devono essere sempre installati in <path>/usr/share/info</path>,
<e>sempre che non siano su X11, o specifici su GNOME o KDE
</e>. Prendete nota: <path>/usr/share/info</path> è la <e>sola</e> locazione ufficiale
per i file GNU info. Da quando gli script <c>./configure</c> li installano in <c>/usr/info</c>
è sempre necessario richiamare <c>./configure</c> con l'argomento <c>--infodir=/usr/share/info</c>.</li>
<li>I file di documentazione sono installati in <path>/usr/share/doc</path>,
in una subdirectory che riflette il nome la versione e la revisione del particolare
programma. Questo va applicato a tutti i programmi: GNOME, KDE, X11 o programmi per console.
Comunque, alcuni programmi possono installare documentazione addizionale o files di supporto
in una directory <path>/usr/share</path> per i loro scopi.
</li>
<li>I programmi specifici per X11 e le librerie devono essere installati dentro <path>/usr</path>,
e non direttamente in <path>/usr/X11R6</path>. Riserviamo questo percorso all'X window system,
versione 11 release 6. Questo è per interpretare più alla lettera le istruzioni di FHS.</li>
<li>I programmi GNOME e KDE, devono essere sempre installati dentro
<path>/usr</path>.</li>
</ul>
<impo>Alcune distribuzioni scelgono di installare GNOME e KDE dentro <path>/opt</path>.
Non esiste uno standard per questi ambienti desktop in termini di dove debbano essere
installati i loro files. Nell'interesse della semplicità e consistenza, abbiamo scelto di
installare tutti i pacchetti GNOME e KDE nella directory <path>/usr</path>.</impo>
<p>In generale, dovete avere gli ebuild che installino i loro files sotto <path>/usr</path>.
<e>Alcuni</e> programmi possono essere compilati e linkati con o senza librerie GNOME, KDE e X11
e possono causare confusione. La nostra soluzione è installare tutto in <path>/usr</path> per
evitare ambiguità e complessità inutili per gli autori degli ebuilds. La locazione nel
filesystem di un programma <e>non</e> deve dipendere dalla presenza o dalla assenza di una variabile <c>USE</c>.
Comunque, tutti gli ebuilds nel portage tree <e>quasi sempre</e> vanno installati in
<path>/usr</path>.</p>
<note>Il path <path>/opt</path> è riservato in Gentoo Linux ai pacchetti binari. Ad esempio
mozilla-bin, acroread, netscape e realplayer. I pacchetti che vengono installati qua
richiedono uno stub file in <path>/etc/env.d/foo</path>. Questo è per includere le variabili
d'ambiente e i percorsi per quei programmi nell'ambiente di esecuzione. Per maggiori informazioni su <path>/etc/env.d</path>, per favore visitate <uri link="http://www.gentoo.org/doc/en/env.d-howto.xml">questo</uri> documento.</note>
</body>
</section>
</chapter>
<chapter>
<title>Gli script Portage e le utility</title>
<section>
<title>Scripts pubblici</title>
<body>
<p>Questi sono gli script usati dall'amministratore di sistema per installare e cancellare
pacchetti e mantenere il database dei pacchetti.</p>
<p><c>ebuild</c> è il motore principale del sistema Portage; esegue i task più importanti
come lo scompattamento, la compilazione, l'installazione, il merging e l'unmerging.
Viene richiamato nel seguente modo: <c>ebuild percorso/al/pacchetto.ebuild comando</c>.
I comandi disponibili sono:</p>
<table>
<tr>
<th>Comando</th>
<th>Descrizione</th>
<th>Funzione <c>ebuild</c></th>
</tr>
<tr>
<ti><c>setup</c>*</ti>
<ti>esegue vari comandi richiesti prima che l'ebuild possa procedere</ti>
<ti><c>pkg_setup</c></ti>
</tr>
<tr>
<ti><c>depend</c></ti>
<ti>visualizza le dipendenze necessarie a installare il pacchetto</ti>
<ti>N/A</ti>
</tr>
<tr>
<ti><c>merge</c>*</ti>
<ti>scompatta, compila, installa e esegue il merge del pacchetto nel vostro filesystem</ti>
<ti>N/A</ti>
</tr>
<tr>
<ti><c>qmerge</c>*</ti>
<ti>esegue il merge del pacchetto nel vostro filesystem, assumendo che lo scompattamento, la compilazione e l'installazione siano già state eseguite</ti>
<ti>N/A</ti>
</tr>
<tr>
<ti><c>unpack</c>*</ti>
<ti>scompatta i sorgenti nella directory di lavoro</ti>
<ti><c>src_unpack</c></ti>
</tr>
<tr>
<ti><c>compile</c>*</ti>
<ti>compila il pacchetto</ti>
<ti><c>src_compile</c></ti>
</tr>
<tr>
<ti><c>rpm</c></ti>
<ti>crea un RPM dal pacchetto</ti>
<ti>N/A</ti>
</tr>
<tr>
<ti><c>package</c></ti>
<ti>crea un pacchetto Gentoo <c>tbz2</c></ti>
<ti>N/A</ti>
</tr>
<tr>
<ti><c>prerm</c>*</ti>
<ti>esegue lo stadio di pre-rimozione del pacchetto</ti>
<ti><c>pkg_prerm</c></ti>
</tr>
<tr>
<ti><c>postrm</c>*</ti>
<ti>esegue lo stadio di post-rimozione del pacchetto</ti>
<ti><c>pkg_postrm</c></ti>
</tr>
<tr>
<ti><c>preinst</c>*</ti>
<ti>esegue lo stadio di pre-installazione del pacchetto</ti>
<ti><c>pkg_preinst</c></ti>
</tr>
<tr>
<ti><c>postinst</c>*</ti>
<ti>esegue lo stadio di post-installazione del pacchetto</ti>
<ti><c>pkg_postinst</c></ti>
</tr>
<tr>
<ti><c>config</c></ti>
<ti>esegue una installazione di default quando al pacchetto viene eseguito il merge</ti>
<ti><c>pkg_config</c></ti>
</tr>
<tr>
<ti><c>touch</c>*</ti>
<ti>aggiorna gli mtimes per ogni archivio sorgente nel pacchetto</ti>
<ti>N/A</ti>
</tr>
<tr>
<ti><c>clean</c>*</ti>
<ti>pulisce la directory di lavoro per il pacchetto</ti>
<ti>N/A</ti>
</tr>
<tr>
<ti><c>fetch</c>*</ti>
<ti>scarica i sorgenti del pacchetto</ti>
<ti>N/A</ti>
</tr>
<tr>
<ti><c>digest</c>*</ti>
<ti>crea il file digest per il pacchetto</ti>
<ti>N/A</ti>
</tr>
<tr>
<ti><c>install</c>*</ti>
<ti>installa il pacchetto nella directory immagine</ti>
<ti><c>src_install</c></ti>
</tr>
<tr>
<ti><c>unmerge</c></ti>
<ti>esegue l'unmerge del pacchetto dal vostro filesystem</ti>
<ti>N/A</ti>
</tr>
</table>
<note>
Nota: i comandi con l'asterisco (*) sono normalmente utilizzati solo dagli sviluppatori.
</note>
<p><c>emerge</c> installa ricorsivamente il pacchetto e le sue dipendenze nel filesystem.
Questo comando ha molte opzioni, provate <c>emerge --help</c> per un elenco.</p>
<p><c>env-update</c> aggiorna i file di configurazione (includendo ma non limitando a <path>/etc/ld.so.conf</path>
e <path>/etc/profile.env</path>) per aggiornare le modifiche dei nuovi pacchetti.</p>
</body>
</section>
<section>
<title>Script e comandi privati</title>
<body>
<p>Questi sono script che potete usare nell'ebuild per eseguire operazioni comuni.</p>
<p>Per maggiori istruzioni, guardate gli script in <path>/usr/lib/portage/bin</path>.</p>
<table>
<tr>
<th>Comando</th>
<th>Valore di default</th>
<th>Descrizione</th>
<th>Esempio</th>
</tr>
<tr>
<ti><c>diropts</c></ti>
<ti>-m0755</ti>
<ti>Setta le opzioni usate quando è in esecuzione <c>dodir</c></ti>
<ti><c>diropts -m0750</c></ti>
</tr>
<tr>
<ti><c>dobin</c></ti>
<ti>N/A</ti>
<ti>Installa i binari specificati in <path>DESTTREE/bin</path></ti>
<ti><c>dobin wmacpi</c></ti>
</tr>
<tr>
<ti><c>docinto</c></ti>
<ti><path>""</path></ti>
<ti>Setta la relativa subdir (<e>DOCDESTTREE</e>) usata da <c>dodoc</c></ti>
<ti><c>docinto examples</c></ti>
</tr>
<tr>
<ti><c>dodir</c></ti>
<ti>N/A</ti>
<ti>Crea una directory, gestisce trasparentemente ${D}</ti>
<ti><c>dodir /usr/lib/newpackage</c></ti>
</tr>
<tr>
<ti><c>dodoc</c></ti>
<ti>N/A</ti>
<ti>Installa i files specificati nella directory di documentazione del pacchetto (<path>/usr/share/doc/${PF}/DOCDESTTREE</path>) (vedere <c>docinto</c>)</ti>
<ti><c>dodoc README *.txt</c></ti>
</tr>
<tr>
<ti><c>doexe</c></ti>
<ti>N/A</ti>
<ti>Installa i file specificati nella modalità <e>EXEOPTIONS</e> (vedere <c>exeopts</c>) in <path>EXEDESTTREE</path> (vedere <c>exeinto</c>)</ti>
<ti><c>doexe ${FILESDIR}/quake3</c></ti>
</tr>
<tr>
<ti><c>dohard</c></ti>
<ti>N/A</ti>
<ti>Crea un hardlink, gestisce trasparentemente ${D}</ti>
<ti><c>dohard ls /bin/dir</c></ti>
</tr>
<tr>
<ti><c>dohtml</c></ti>
<ti>N/A</ti>
<ti>Installa i file specificati e le directory in <path>/usr/share/doc/${PF}/html</path></ti>
<ti><c>dohtml -r doc/html/*</c></ti>
</tr>
<tr>
<ti><c>doinfo</c></ti>
<ti>N/A</ti>
<ti>Installa i file specificati in /usr/share/info, e li comprime con gzip</ti>
<ti><c>doinfo doc/*.info</c></ti>
</tr>
<tr>
<ti><c>doins</c></ti>
<ti>N/A</ti>
<ti>Installa i file specificati con modalità <c>INSOPTIONS</c> (vedere <c>insopts</c>) in <path>INSDESTTREE</path> (vedere <c>insinto</c>)</ti>
<ti><c>doins *.png icon.xpm</c></ti>
</tr>
<tr>
<ti><c>dolib</c></ti>
<ti>N/A</ti>
<ti>Installa le librerie specificate in <path>DESTTREE/lib</path> con modalità 0644</ti>
<ti><c>dolib *.a *.so</c></ti>
</tr>
<tr>
<ti><c>dolib.a</c></ti>
<ti>N/A</ti>
<ti>Installa le librerie specificate in <path>DESTTREE/lib</path> con modalità 0644</ti>
<ti><c>dolib.a *.a</c></ti>
</tr>
<tr>
<ti><c>dolib.so</c></ti>
<ti>N/A</ti>
<ti>Installa le librerie specificate in <path>DESTTREE/lib</path> con modalità 0755</ti>
<ti><c>dolib.so *.so</c></ti>
</tr>
<tr>
<ti><c>doman</c></ti>
<ti>N/A</ti>
<ti>Installa i file specificati in <path>/usr/share/man/manX</path>, in accordo con il suffisso del file (file.1 andrà in <path>man1</path></ti>
<ti><c>doman *.1 *.5</c></ti>
</tr>
<tr>
<ti><c>dosbin</c></ti>
<ti>N/A</ti>
<ti>Installa i file in <path>DESTTREE/sbin</path>, assicurandosi che sono eseguibili</ti>
<ti><c>dosbin ksymoops</c></ti>
</tr>
<tr>
<ti><c>dosym</c></ti>
<ti>N/A</ti>
<ti>Crea un symlink, gestisce trasparentemente ${D}</ti>
<ti><c>dosym gzip /bin/zcat</c></ti>
</tr>
<tr>
<ti><c>emake</c></ti>
<ti>N/A</ti>
<ti>Esegue make con <c>MAKEOPTS</c>. alcuni pacchetti non possono essere fatti in parallelo; usare invece <c>emake -j1</c></ti>
<ti><c>emake</c></ti>
</tr>
<tr>
<ti><c>exeinto</c></ti>
<ti><path>/</path></ti>
<ti>Setta root (<e>EXEDESTTREE</e>) per il comando <c>doexe</c></ti>
<ti><c>exeinto /usr/lib/${PN}</c></ti>
</tr>
<tr>
<ti><c>exeopts</c></ti>
<ti>-m0755</ti>
<ti>Setta le opzioni usate quando si esegue <c>doexe</c></ti>
<ti><c>exeopts -m1770</c></ti>
</tr>
<tr>
<ti><c>fowners</c></ti>
<ti>N/A</ti>
<ti>Applica la proprietà specificata ai file specificati tramite il comando chown, gestisce trasparentemente ${D}</ti>
<ti><c>fowners root:root /sbin/functions.sh</c></ti>
</tr>
<tr>
<ti><c>fperms</c></ti>
<ti>N/A</ti>
<ti>Applica i permessi specificati ai file specificati tramite il comando chmod, gestisce trasparentemente ${D}</ti>
<ti><c>fperms 700 /var/consoles</c></ti>
</tr>
<tr>
<ti><c>insinto</c></ti>
<ti><path>/usr</path></ti>
<ti>Setta root (<e>INSDESTTREE</e>) per il comando <c>doins</c></ti>
<ti><c>insinto /usr/include</c></ti>
</tr>
<tr>
<ti><c>insopts</c></ti>
<ti>-m0644</ti>
<ti>Setta le opzioni usate quando si esegue <c>doins</c></ti>
<ti><c>insopts -m0444</c></ti>
</tr>
<tr>
<ti><c>into</c></ti>
<ti><path>/usr</path></ti>
<ti>Setta il prefix target (<path>DESTTREE</path>) per tutti i comandi 'do' (come <c>dobin</c>, <c>dolib</c>, <c>dolib.a</c>, <c>dolib.so</c>, <c>domo</c>, <c>dosbin</c>)</ti>
<ti><c>into /</c></ti>
</tr>
<tr>
<ti><c>libopts</c></ti>
<ti>-m0644</ti>
<ti>Setta le opzioni quando si esegue <c>dolib</c></ti>
<ti><c>libopts -m0555</c></ti>
</tr>
<tr>
<ti><c>newbin</c></ti>
<ti>N/A</ti>
<ti>Wrapper di <c>dobin</c> che installa il binario specificato trasparentemente rinominando il secondo argomento</ti>
<ti><c>newbin ${FILESDIR}/vmware.sh vmware</c></ti>
</tr>
<tr>
<ti><c>newdoc</c></ti>
<ti>N/A</ti>
<ti>Wrapper di <c>dodoc</c> che installa il file specificato trasparentemente rinominando il secondo argomento</ti>
<ti><c>newdoc README README.opengl</c></ti>
</tr>
<tr>
<ti><c>newexe</c></ti>
<ti>N/A</ti>
<ti>Wrapper di <c>doexe</c> che installa il file specificato trasparentemente rinominando il secondo argomento</ti>
<ti><c>newexe ${FILESDIR}/xinetd.rc xinetd</c></ti>
</tr>
<tr>
<ti><c>newins</c></ti>
<ti>N/A</ti>
<ti>Wrapper di <c>doins</c> che installa il file specificato trasparentemente rinominando il secondo argomento</ti>
<ti><c>newins ntp.conf.example ntp.conf</c></ti>
</tr>
<tr>
<ti><c>newman</c></ti>
<ti>N/A</ti>
<ti>Wrapper di <c>doman</c> che installa il file specificato trasparentemente rinominando il secondo argomento</ti>
<ti><c>newman xboing.man xboing.6</c></ti>
</tr>
<tr>
<ti><c>newsbin</c></ti>
<ti>N/A</ti>
<ti>Wrapper di <c>dosbin</c> che installa il file specificato trasparentemente rinominando il secondo argomento</ti>
<ti><c>newsbin strings strings-static</c></ti>
</tr>
<tr>
<ti><c>prepall</c></ti>
<ti>N/A</ti>
<ti>Esegue <c>prepallman</c>, <c>prepallinfo</c> e <c>prepallstrip</c>. Si accerta anche che tutte le librerie in <path>/opt/*/lib</path>, <path>/lib</path>, <path>/usr/lib</path> e <path>/usr/X11R6/lib</path> siano eseguibili. sposta anche le macro aclocal in <path>/usr/share/aclocal</path></ti>
<ti><c>prepall</c></ti>
</tr>
<tr>
<ti><c>prepalldocs</c></ti>
<ti>N/A</ti>
<ti>Gzippa ricorsivamente tutti i file doc in <path>/usr/share/doc</path>, aggiustando trasparentemente ogni percorso symlink</ti>
<ti><c>prepalldocs</c></ti>
</tr>
<tr>
<ti><c>prepallinfo</c></ti>
<ti>N/A</ti>
<ti>Gzippa ricorsivamente tutti i file info in <path>/usr/share/info</path></ti>
<ti><c>prepallinfo</c></ti>
</tr>
<tr>
<ti><c>prepallman</c></ti>
<ti>N/A</ti>
<ti>Gzippa ricorsivamente tutte le man pages in <path>/opt/*/man/*</path>, <path>/usr/share/man/*</path>, <path>/usr/local/man/*</path>, <path>/usr/X11R6/share/man/*</path> e aggiusta trasparentemente ogni percorso symlink</ti>
<ti><c>prepallman</c></ti>
</tr>
</table>
</body>
</section>
</chapter>
<chapter>
<title>Dipendenze dei pacchetti</title>
<section>
<title>Perchè le dipendenze sono importanti</title>
<body>
<p>Portage è più di un semplice script conveniente che dà un modo unificato di
costruire un pacchetto (programma, libreria) dai sorgenti. E` anche un modo di scaricare
e installare le dipendenze necessarie se si sta attenti ad esse nell'ebuild.</p>
<p>Negli ebuild ufficiali, tutte le dipendenze vengono specificate, quindi quando
si esegue <c>emerge net-www/mozilla/mozilla-1.0</c>, Portage si assicurerà che
tutte le librerie necessarie a mozilla siano installate prima di costruirlo.</p>
<p>Portage distingue le dipendenze build-time e run-time. (Correntemente, Portage
installa tutte le dipendenze e le lascia. In uno stage successivo può essere possibile
che siano cancellate le librerie build-time e lasciate solo le run-time).
</p>
</body>
</section>
<section>
<title>Come specificare le dipendenze nei vostri files ebuild (a.k.a. DEPEND Atoms)</title>
<body>
<p>La variabile <c>DEPEND</c> nel vostro ebuild <path>foo-x.y.z.ebuild</path>
dice a Portage quali pacchetti sono necessari per costruire <path>foo</path>. La variabile
<c>RDEPEND</c> specifica quali pacchetti sono necessari a <path>foo</path> per essere eseguito.
</p>
<pre>
DEPEND="virtual/glibc
sys-libs/zlib"
RDEPEND="virtual/glibc"
</pre>
<p>Ciò dice a Portage che per costruire <path>foo-x.y.z</path> i pacchetti
<path>virtual/glibc</path> e <path>sys-libs/zlib</path>
sono necessari. Non dice niente su quale versione di glibc o zlib sia richiesta
il che significa che non fa niente.</p>
<p>Il "non fa niente" è un pò stupido e non funzionerà generalmente. Però per librerie
centrali come glibc che deve essere al 100% compatibile con i binari, funziona.
Per le altre librerie, possiamo specificare le versioni delle dipendenze.</p>
<pre>
>=sys-apps/bar-1.2
=sys-apps/baz-1.0
</pre>
<p> >= e = fanno quello che vi aspettate; sys-apps/bar versione 1.2 o più nuova va bene
(ciò significa che sys-apps/bar-2.0 è okay), mentre sys-apps/baz versione 1.0 è la sola accettata. Per maggiori informazioni sullo schema delle versioni dei pacchetti, vedere la sezione sopra <uri link="#doc_chap2_sect2">Dare il nome ai file ebuild</uri>.</p>
<p>Altri modi di specificare le dipendenze delle versioni sono i seguenti:</p>
<pre>
~sys-apps/qux-1.0
=sys-apps/foo-1.2*
!sys-libs/gdbm
</pre>
<p>~sys-apps/qux-1.0 sceglierà la revisione più nuova di qux-1.0</p>
<p>=sys-apps/foo-1.2* sceglierà il membro più nuovo della serie 1.2 e ignorerà le serie
1.3 e quelle più avanti/indietro. Ciò significa che foo-1.2.3 e foo-1.2.0 sono valide, mentre
foo-1.3.3, foo-1.3.0, e foo-1.1.0 non lo sono.</p>
<p>!sys-libs/gdbm impedirà a questo pacchetto di fare il merge poichè gdbm è già installato.</p>
<note>
Per tutti gli ultimi dettagli su DEPEND Atoms, per favore vedere la sezione 5 della manpage sugli ebuilds. <c>man 5 ebuilds</c>.
</note>
</body>
</section>
</chapter>
<chapter>
<title>Testare e distribuire</title>
<section>
<title>ChangeLog</title>
<body>
<p>Quando si aggiorna (o si scrive un nuovo) ebuild bisogna sempre aggiornare il suo ChangeLog.
Il file <path>skel.ChangeLog</path> contiene un semplice ChangeLog da usare come base.</p>
<p>Lo scopo del ChangeLog è documentare <e>cosa</e> è stato fatto, <e>perchè</e> è stato fatto
e da <e>chi</e>. Questo permette a sviluppatori e utenti di tracciare i cambiamenti in maniera semplice.</p>
<p>Il Changelog è primariamente destinato agli utenti, quindi siate sicuri di scriverlo corto,
puntuale ed evitare di essere troppo precisi nei dettagli tecnici.</p>
</body>
</section>
<section>
<title>Memorizzare i vostri ebuilds localmente</title>
<body>
<p>
Per poter testare i vostri ebuilds e lasciare che Portage li riconosca, dovete disporli in una directory conosciuta. Portage userà la variabile <c>PORTDIR_OVERLAY</c> che potete definire in <path>/etc/make.conf</path>. Dovreste settare questa variabile alla vostra directory (per esempio <path>/usr/local/portage</path>).
</p>
<p>
In questa directory, dovete usare la stessa struttura (e le stesse categorie) di <path>/usr/portage</path>.
</p>
<p>
Usando <c>PORTDIR_OVERLAY</c>, i vostri ebuilds rimangono nel vostro sistema, anche dopo un <c>emerge sync</c>, e sono ancora riconosciuti da Portage.
</p>
</body>
</section>
<section>
<title>Tool utili per i test</title>
<body>
<p>Abbiamo degli utili tool per aiutarvi con la scrittura e il mantenimento dei vostri ebuilds.</p>
<warn>
<c>lintool</c>, è rovinato, usate repoman.
</warn>
<table>
<tr>
<th>Tool</th>
<th>Pacchetto</th>
<th>Descrizione</th>
</tr>
<tr>
<ti><c>repoman</c></ti>
<ti>sys-apps/portage</ti>
<ti>Tool per sviluppatori che aiuta nella procedura di checkin al CVS. Fa molte comuni QA e cerca di assicurare che i file aggiunti al cvs non romperanno il portage tree.</ti>
</tr>
<tr>
<ti><c>ccache</c></ti>
<ti>dev-util/ccache</ti>
<ti>Tool che mantiene i file già installati così che la ricompilazione si ottiene più velocemente. Assicuratevi di aggiungere <c>ccache</c> alla variabile <c>FEATURES</c> in <path>/etc/make.conf</path>!
</ti>
</tr>
<tr>
<ti><c>sandboxshell</c></ti>
<ti>app-shells/sandboxshell</ti>
<ti>Lancia una shell che crea un ambiente sandbox. Utile per entrare all'interno dello stesso ambiente in cui portage costruisce i pacchetti e mettere a punto le cose a mano.</ti>
</tr>
<tr>
<ti><c>echangelog</c></ti>
<ti>app-portage/gentoolkit</ti>
<ti>Può creare un nuovo Changelog o aggiungere una voce in uno già esistente.</ti>
</tr>
<tr>
<ti><c>gentool-bump-revision</c></ti>
<ti>app-portage/gentoolkit</ti>
<ti>Tool per sviluppatori che aggiunge un numero di revisione, aggiunge la nuova revisione al CVS, rimuove le vecchie revisioni e aggiorna di conseguenza il Changelog.</ti>
</tr>
<tr>
<ti><c>qpkg</c></ti>
<ti>app-portage/gentoolkit</ti>
<ti>Un tool per raccogliere varie informazioni sui pacchetti installati.</ti>
</tr>
</table>
</body>
</section>
</chapter>
</guide>
|
GitWeb