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
|
<?xml version="1.0"?>
<guide self="ebuild-writing/misc-files/metadata/">
<chapter>
<title>Package and Category <c>metadata.xml</c></title>
<body>
<p>
The <c>metadata.xml</c> file is used to specify additional data about a
package or category.
</p>
</body>
<section>
<title>Syntax</title>
<body>
<p>
A metadata file follows the syntax defined in
<uri link="https://www.gentoo.org/glep/glep-0068.html">GLEP 68</uri>.
The character set <b>must</b> be UTF-8 as specified by
<uri link="https://www.gentoo.org/glep/glep-0031.html">GLEP 31</uri>.
</p>
<p>
Concerning indentation there is no strict rule governing the style and
width. However the following minimal set of rules need to be followed:
</p>
<ul>
<li>
Indentation should be consistent, i.e. either spaces or tabs, but
not both.
</li>
<li>
Keep the existing style when touching metadata.xml files that
belong to other developers.
</li>
</ul>
<p>
The following table summarizes the tags that may appear in a
metadata.xml:
</p>
<table>
<tr>
<th>tag</th>
<th>description</th>
</tr>
<tr>
<ti>
<c><catmetadata></c>
</ti>
<ti>
This is the root element of the <c>metadata.xml</c> file for
categories. It has no attributes. It contains a number of
<c><longdescription></c> tags, each for a different language.
</ti>
</tr>
<tr>
<ti>
<c><pkgmetadata></c>
</ti>
<ti>
This is the root element of the <c>metadata.xml</c> file for
packages. It has no attributes. The following subtags are
allowed:
<c><maintainer></c>,
<c><longdescription></c>,
<c><stabilize-allarches></c>,
<c><slots></c>,
<c><use></c>, and
<c><upstream></c>.
While all the subtags are optional, <upstream> may
appear at most once.
</ti>
</tr>
<tr>
<ti>
<c><maintainer></c>
</ti>
<ti>
This tag specifies the persons and/or projects responsible for
the maintenance of a package. The <c>type</c> attribute must
be specified and can be either <c>"person"</c> or <c>"project"</c>.
There is one required subtag:
<c><email></c>. It has two optional subtags:
<c><name></c> and
<c><description></c>.
</ti>
</tr>
<tr>
<ti><c><email></c></ti>
<ti>
This contains the e-mail address of the maintainer. It is required.
</ti>
</tr>
<tr>
<ti><c><name></c></ti>
<ti>
This contains freetext with the name of the maintainer. It is optional.
</ti>
</tr>
<tr>
<ti><c><description></c></ti>
<ti>
The description tag contains a description of the maintainership, or for
example a remark that someone interested can take over the maintainership.
It is optional.
</ti>
</tr>
<tr>
<ti><c><longdescription></c></ti>
<ti>
This tag contains a description for a category or a package.
For packages, it is used to augment the
<uri link="::ebuild-writing/variables/#Ebuild-defined Variables">
DESCRIPTION</uri> field in the ebuilds themselves. This tag has
two optional subtags: <c><pkg></c> and <c><cat></c>.
</ti>
</tr>
<tr>
<ti><c><stabilize-allarches></c></ti>
<ti>
Indicates an architecture-independent package. An ebuild can be marked
stable for all relevant architectures, when it has been tested on only one
architecture. This tag must have empty content.
</ti>
</tr>
<tr>
<ti><c><slots></c></ti>
<ti>
This tag describes the
<uri link="::general-concepts/slotting">slots</uri> of a package.
It has two optional subtags:
<c><slot></c> and <c><subslots></c>.
</ti>
</tr>
<tr>
<ti><c><slot></c></ti>
<ti>
This contains information for a particular slot. The <c>name</c>
attribute is mandatory and specifies the name of the slot.
</ti>
</tr>
<tr>
<ti><c><subslots></c></ti>
<ti>
Describes the meaning of subslots for the whole package. This
tag may appear at most once.
</ti>
</tr>
<tr>
<ti><c><use></c></ti>
<ti>
This tag contains descriptions of
<uri link="::ebuild-writing/variables/#IUSE">USE flags</uri>.
This tag is optional and, if specified, has one required subtag:
<c><flag></c>.
</ti>
</tr>
<tr>
<ti><c><flag></c></ti>
<ti>
This tag contains a description of how the named USE flag affects this
package. It is required if the <c><use></c> tag is specified.
It also requires the USE flag to be named in the <c>name</c> attribute.
This tag has two optional subtags: <c><pkg></c> and
<c><cat></c>.
</ti>
</tr>
<tr>
<ti><c><upstream></c></ti>
<ti>
This tag contains information about the upstream developers/project.
It supports multiple optional subtags: <c><maintainer></c>,
<c><changelog></c>, <c><doc></c>,
<c><bugs-to>,</c>, and <c><remote-id></c>.
</ti>
</tr>
<tr>
<ti><c><maintainer></c></ti>
<ti>
Provides information about the upstream maintainer. It requires a
<c><name></c> subtag to be specified, supports an optional
<c><email></c> subtag and an optional <c>status</c> attribute.
Note that the <c>type</c> attribute <e>must not</e> be specified
for upstream maintainers.
</ti>
</tr>
<tr>
<ti><c><name></c></ti>
<ti>
The name of an upstream maintainer should contain a block of text with upstream's name.
This element is mandatory for an upstream maintainer and must appear exactly once.
</ti>
</tr>
<tr>
<ti><c><email></c></ti>
<ti>
The email address of an upstream maintainer. May appear only once.
</ti>
</tr>
<tr>
<ti><c><changelog></c></ti>
<ti>
Should contain a URL where the location of the upstream changelog can be found.
The URL must be version independent and must point to a changelog which is only
updated on new releases of the corresponding package. (This also implies that
one can link to an automatically updated changelog in case of vcs snapshots
only). May appear at most once.
</ti>
</tr>
<tr>
<ti><c><doc></c></ti>
<ti>
Should contain a URL where the location of the upstream documentation can be
found. The link must not point to any third party documentation and must be
version independent. If the documentation is available in more than one language,
a lang attribute can be used which follows the same rules as the one for
<c><longdescription></c>.
</ti>
</tr>
<tr>
<ti><c><bugs-to></c></ti>
<ti>
Should contain a place where bugs can be filed, a URL or an e-mail address prefixed
with <c>mailto:</c>. May appear at most once.
</ti>
</tr>
<tr>
<ti><c><remote-id></c></ti>
<ti>
Should specify a type of package identification tracker and the identification that
corresponds to the package in question. remote-id should make it easier to index
information such as its Freshmeat ID or its CPAN name.
It has a mandatory attribute <c>type</c> which identifies the type
of upstream source.
</ti>
</tr>
<tr>
<ti><c><pkg></c></ti>
<ti>
This tag contains a valid qualified package name.
</ti>
</tr>
<tr>
<ti><c><cat></c></ti>
<ti>
This tag contains a valid category name as defined in
<c>profiles/categories</c>.
</ti>
</tr>
</table>
<p>
There are also some attributes that can be used with these tags:
</p>
<table>
<tr>
<th>attribute</th>
<th>tags</th>
<th>description</th>
</tr>
<tr>
<ti>lang</ti>
<ti>
<c><description></c>, <c><longdescription></c>,
<c><slots></c>, <c><use></c>, <c><doc></c>
</ti>
<ti>
In every case where a description is required, there must be at
<e>least</e> an english description. If an additional description in
another language is given, this attribute is used to specify the language
used. The format is the two-character language code as defined by the <uri
link="https://www.w3.org/WAI/ER/IG/ert/iso639.htm#2letter">ISO-639-1</uri>
norm.
</ti>
</tr>
<tr>
<ti>restrict</ti>
<ti>
<c><maintainer></c>, <c><longdescription></c>,
<c><stabilize-allarches></c>, <c><flag></c>
</ti>
<ti>
The restrict attribute allows one to restrict the application of
certain tags to certain versions of a package. When this attribute
is used, other tags with or without the restrict attribute must be
present to cover all the versions of the package. A tag without
the restrict attribute serves as the default. The format of the
restrict attribute is that of a EAPI=0 package dependency specification
(i.e., USE-conditional or slot dependendencies are not allowed).
Since <c><</c> and <c>></c> are special characters in XML,
they must be escaped using <c>&lt;</c> and <c>&gt;</c>.
</ti>
</tr>
<tr>
<ti>name</ti>
<ti>
<c><flag></c>, <c><slot></c>
</ti>
<ti>
When this attribute is required on the <c><flag></c> tag, it
simply contains the name of the USE flag. For the
<c><slot></c> tag, it specifies the
<uri link="::general-concepts/slotting/#Slot Names">
slot name</uri> to which it applies. A slot name of <c>*</c>
allows for a single <c><slot></c> tag to match all the slots of a
package, in which case no other slot tags may be present.
</ti>
</tr>
<tr>
<ti>status</ti>
<ti>
<c><maintainer></c>
</ti>
<ti>
The upstream maintainer element has a status attribute, which is
one of <c>"active"</c> or <c>"inactive"</c>. This attribute is not
mandatory. The absence of it shall be interpreted as
<c>"unknown"</c>. Please note that this attribute is only allowed
for the <c><maintainer></c> subtags of the <c><upstream></c>
element!
</ti>
</tr>
<tr>
<ti>type</ti>
<ti>
<c><remote-id></c>
</ti>
<ti>
A string identifying the type of upstream source. A list of valid strings are kept in
<uri link="https://www.gentoo.org/dtd/metadata.dtd">metadata.dtd</uri>.
Developers should email the gentoo-dev mailing list before using a new type value.
</ti>
</tr>
<tr>
<ti>type</ti>
<ti>
<c><maintainer></c>
</ti>
<ti>
Defines the type of the maintainer for a package. There are only
two valid values: <c>"person"</c> and <c>"project"</c>. The latter
denotes an official
<uri link="::general-concepts/projects">
Gentoo project</uri>.
</ti>
</tr>
</table>
</body>
</section>
<section>
<title>Package Metadata</title>
<body>
<p>
All packages <b>must</b> include a <c>metadata.xml</c> file which
provides information about package description, maintainers, local USE
flags, upstream etc.
</p>
<p>
For developers' convenience, a skeleton file is provided in the
Gentoo tree with the name
<uri link="https://gitweb.gentoo.org/repo/gentoo.git/tree/skel.metadata.xml">
skel.metadata.xml</uri>. The metadata file can also be created
using the <c>app-portage/metagen</c> tool.
</p>
<p>
Commits of package metadata files are handled by <c>pkgdev</c> as
part of regular package maintenance.
</p>
<p>
Unless specified otherwise, the maintainer who is listed in the
metadata first shall be the assignee for the bugs for that package as
per <uri link="https://www.gentoo.org/glep/glep-0067.html#bug-assignment">
GLEP 67</uri>.
</p>
</body>
<subsection>
<title>Package Metadata Examples</title>
<body>
<p>
In the following sections, various examples of metadata.xml are
provided. These examples are based on actual package metadata files to
keep things as realistic as possible. However, they may not include
these files verbatim and should be taken as hypothetical examples.
</p>
</body>
<subsubsection>
<title>Projects as Maintainers</title>
<body>
<p>
For the first example, a package maintained by a single project is
presented. It is a simplified version of <c>metadata.xml</c> for
the package <c>app-office/libreoffice</c>. The package
maintainer is identified by the email address <c>office@gentoo.org</c>
with the name <c>Gentoo Office Project</c> as specified in the
optional <c><name></c> subtag. It also provides a long package
description.
</p>
<codesample lang="sgml">
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkgmetadata SYSTEM "https://www.gentoo.org/dtd/metadata.dtd">
<pkgmetadata>
<maintainer type="project">
<email>office@gentoo.org</email>
<name>Gentoo Office Project</name>
</maintainer>
<longdescription>
LibreOffice is the successor of OpenOffice.org. This ebuild
allows you to compile it yourself. Unfortunately this compilation can
take up to a day depending on the speed of your computer. It will
however make a snappier LibreOffice than the binary version.
</longdescription>
</pkgmetadata>
</codesample>
<p>
The email address <c>office@gentoo.org</c> corresponds to the
<c>Gentoo Office Project</c> as defined in
<uri link="https://api.gentoo.org/metastructure/projects.xml">
projects.xml</uri>. This file lists all the projects in Gentoo and it
is generated from the
<uri link="https://wiki.gentoo.org/wiki/Project:Gentoo">
projects listing</uri> available on the Gentoo Wiki:
</p>
<codesample lang="sgml">
<project>
<email>office@gentoo.org</email>
<name>Gentoo Office Project</name>
<url>https://wiki.gentoo.org/wiki/Project:Office</url>
<description>
The Office project manages the office implementations
and related packages in Gentoo.
</description>
<member>
<email>dilfridge@gentoo.org</email>
<name>Andreas K. Hüttel</name>
<role>member</role>
</member>
<member>
<email>scarabeus@gentoo.org</email>
<name>Tomáš Chvátal</name>
<role>member</role>
</member>
</project>
</codesample>
</body>
</subsubsection>
<subsubsection>
<title>Local USE Flag Descriptions</title>
<body>
<p>
The second example is formed after the <c>metadata.xml</c> of
<c>sys-apps/portage</c>. It lists multiple maintainers where one
is a developer and the other is a project. It illustrates how local
USE flag descriptions are specified and also contains an upstream
element. It is also worth pointing out the use of <c>mailto:</c>
prefix in <c><bugs-to></c> tag due to the presence of an email address
as opposed to a URL. Conversely, email addresses specified in the
<c><email></c> tags require no such prefix.
</p>
<codesample lang="sgml">
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkgmetadata SYSTEM "https://www.gentoo.org/dtd/metadata.dtd">
<pkgmetadata>
<maintainer type="person">
<email>larry@gentoo.org</email>
<name>Larry the Cow</name>
</maintainer>
<maintainer type="project">
<email>dev-portage@gentoo.org</email>
</maintainer>
<use>
<flag name="epydoc">Build html API documentation with epydoc.</flag>
<flag name="ipc">Use inter-process communication between Portage and running ebuilds.</flag>
<flag name="pypy2_0">Use pypy-c2.0 as Python interpreter.</flag>
<flag name="python2">Use python2 as Python interpreter.</flag>
<flag name="python3">Use python3 as Python interpreter.</flag>
<flag name="xattr">
Preserve extended attributes (filesystem-stored metadata) when
installing files. Usually only required for hardened systems.
</flag>
</use>
<upstream>
<bugs-to>mailto:dev-portage@gentoo.org</bugs-to>
<changelog>https://gitweb.gentoo.org/proj/portage.git/plain/RELEASE-NOTES</changelog>
<doc>https://wiki.gentoo.org/wiki/Handbook:AMD64/Working/Portage</doc>
</upstream>
</pkgmetadata>
</codesample>
</body>
</subsubsection>
<subsubsection>
<title>Split Maintainership</title>
<body>
<p>
This example splits the maintainership based on package versions using
the attribute <c>restrict</c>. According to the
<c>metadata.xml</c> of <c>sys-boot/grub</c>, the ebuilds
for version 2 and above are maintained by floppym@gentoo.org whereas
earlier versions are maintained by the Gentoo Base System
project. Note the use of "&gt;" as opposed to ">" in
<c>restrict</c>.
</p>
<p>
The example also uses the <c><pkg></c> tag in USE flag
descriptions. Slot dependency specifiers are not allowed inside
<c><pkg></c>, therefore the notation
<c><pkg>sys-boot/grub</pkg>:2</c> is adopted as opposed to
<c><pkg>sys-boot/grub:2</pkg></c>.
</p>
<p>
Lastly, the <c><remote-id></c> tag in the upstream description
is demonstrated.
</p>
<codesample lang="sgml">
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkgmetadata SYSTEM "https://www.gentoo.org/dtd/metadata.dtd">
<pkgmetadata>
<maintainer restrict="&gt;=sys-boot/grub-2" type="person">
<email>floppym@gentoo.org</email>
</maintainer>
<maintainer type="project">
<email>base-system@gentoo.org</email>
<name>Gentoo Base System</name>
</maintainer>
<use>
<flag name="device-mapper">
Enable support for device-mapper from <pkg>sys-fs/lvm2</pkg>
</flag>
<flag name="efiemu">
Build and install the efiemu runtimes
</flag>
<flag name="fonts">Build and install fonts for the gfxterm module</flag>
<flag name="mount">
Build and install the grub-mount utility
</flag>
<flag name="libzfs">
Enable support for <pkg>sys-fs/zfs</pkg>
</flag>
<flag name="multislot">
Allow concurrent installation of <pkg>sys-boot/grub</pkg>:0 and
<pkg>sys-boot/grub</pkg>:2 by renaming all programs.
</flag>
<flag name="themes">Build and install GRUB themes (starfield)</flag>
<flag name="truetype">
Build and install grub-mkfont conversion utility
</flag>
</use>
<upstream>
<remote-id type="sourceforge">dejavu</remote-id>
</upstream>
</pkgmetadata>
</codesample>
</body>
</subsubsection>
<subsubsection>
<title>Slots and Subslots</title>
<body>
<p>
The main focus of this example is to demonstrate how slots and
subslots are specified, by examining the metadata of
<c>media-libs/libpng</c>. There may be multiple reasons for
slotting depending on the nature of the package. For this particular
package, it can be seen that the slots are used to provide different
versions of the library with varying binary compatibility and that
developers are advised to build against the slot 0. Furthermore,
different versions of this package with the same subslot provide the
same Application Binary Interface (ABI), according to the description
specified in the <c><subslots></c> tag.
</p>
<codesample lang="sgml">
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkgmetadata SYSTEM "https://www.gentoo.org/dtd/metadata.dtd">
<pkgmetadata>
<maintainer type="project">
<email>base-system@gentoo.org</email>
<name>Gentoo Base System</name>
</maintainer>
<use>
<flag name="apng">support unofficial APNG (Animated PNG) spec</flag>
</use>
<upstream>
<remote-id type="cpe">cpe:/a:libpng:libpng</remote-id>
<remote-id type="sourceforge">apng</remote-id>
</upstream>
<slots>
<slot name="0">
For building against. This is the only slot
that provides headers and command line tools.
</slot>
<slot name="1.2">
For binary compatibility, provides libpng12.so.0 only.
</slot>
<slot name="1.5">
For binary compatibility, provides libpng15.so.15 only.
</slot>
<subslots>Reflect ABI compatibility for libpng.so.</subslots>
</slots>
</pkgmetadata>
</codesample>
</body>
</subsubsection>
</subsection>
<subsection>
<title>Maintainer-Needed</title>
<body>
<p>
Maintainer-needed ("orphaned") packages have no maintainers responsible for
them. Per
<uri link="https://www.gentoo.org/glep/glep-0067.html#case-of-maintainer-needed-packages">
GLEP 67</uri>, these packages must not contain any <c><maintainer></c>
subtags under <c><pkgmetadata></c> in their <c>metadata.xml</c>. A strict
test for this condition would be:
</p>
<pre>
[[ $(xmllint --xpath "count(/pkgmetadata/maintainer)" metadata.xml) -eq 0 ]]
</pre>
<p>
By convention, a comment line containing the string <c>maintainer-needed</c>
is inserted. Other tags which are relevant to the package may be
present in the metadata. Bugs for these packages must be assigned to
<c>maintainer-needed@gentoo.org</c>. The QA team periodically generates the
<uri link="https://qa-reports.gentoo.org/output/maintainer-needed.html">
orphaned packages list</uri> along with their corresponding bugs as
part of the QA reports.
</p>
<codesample lang="sgml">
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkgmetadata SYSTEM "https://www.gentoo.org/dtd/metadata.dtd">
<pkgmetadata>
<!-- maintainer-needed -->
<upstream>
<maintainer status="active">
<email>rasmus@alum.mit.edu</email>
<name>Matt Rasmussen</name>
</maintainer>
<doc lang="en">http://keepnote.org/manual/</doc>
<bugs-to>https://code.google.com/p/keepnote/issues/list</bugs-to>
</upstream>
<longdescription lang="en">
KeepNote is a note taking application. With KeepNote, you can
store your class notes, TODO lists, research notes, journal entries,
paper outlines, etc in a simple notebook hierarchy with rich-text
formatting, images, and more. Using full-text search, you can
retrieve any note for later reference.
</longdescription>
</pkgmetadata>
</codesample>
</body>
</subsection>
</section>
<section>
<title>Category Metadata</title>
<body>
<p>
For categories, <c>metadata.xml</c> specifies a long description (in
English and optionally in other languages). A typical example:
</p>
<codesample lang="sgml">
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE catmetadata SYSTEM "https://www.gentoo.org/dtd/metadata.dtd">
<catmetadata>
<longdescription lang="en">
The app-vim category contains plugins and syntax file
packages for the Vim text editor.
</longdescription>
<longdescription lang="de">
Die Kategorie app-vim enthält Plugins und Syntax-Pakete
für den Vim Texteditor.
</longdescription>
</catmetadata>
</codesample>
<p>
When creating a new category, creating a <c>metadata.xml</c> file
along with a <c><longdescription></c> in English is
<b>mandatory</b>. Translations are handled by any interested developer
who speaks a language sufficiently well.
</p>
<p>
The correct way to commit a <e>category</e> <c>metadata.xml</c> file
is currently:
</p>
<pre>
xmllint --noout --valid metadata.xml
git add metadata.xml
git commit --gpg-sign
</pre>
<p>
The commit message should be formatted properly.
A sample commit is shown below:
</p>
<pre>
commit db359439bcd52f5a7f20d2332ab62feb16657504
Author: Alexis Ballier <aballier@gentoo.org>
Date: Tue Sep 22 10:47:49 2015 +0200
dev-ros: Add metadata.xml for the category.
</pre>
</body>
</section>
</chapter>
</guide>
|
GitWeb