Gentoo Archives: gentoo-dev

From: Paul de Vrieze <pauldv@g.o>
To: gentoo-dev@g.o
Cc: gentoo-core@g.o
Subject: [gentoo-dev] IMPORTANT: The proposal for the metadata.xml file
Date: Fri, 27 Jun 2003 20:48:44
1 First let me introduce the context of this proposal.
3 This proposal is a vital step in making herds work. This proposal proposes the
4 format of the metadata file. This proposed file is the result of a process in
5 which a number of developers where involved. Before implementing metadata
6 files, we want some extra input, and I will make sure that this input is
7 taken into account in the final format.
9 I would like the input from all of you on the files. Note that metadata.dtd is
10 the most important one, and db.metadata.xml is an example for the sys-lib/db
11 package, that shows some of the features of the dtd. The example is not meant
12 to be exhaustive, though.
17 Below I will write out the reasons for certain choices that have been made. I
18 have also put in and
19 IRC log of a discussion of 26 May with me, absinthe, drobbins, danarmak and
20 others on this topic.
22 - We need to have herds. For that we need to be able to assign packages to
23 herds. While we first thought a MAINTAINER file was enough, through
24 discussions we found that there is more information we want to have about a
25 package, and that we are probably going to want to add more even later on.
26 For this XML was chosen as an implementation format for this file.
28 There must be rather strong arguments against it to let go the choice of XML
30 - We need ways to have people or herds only responsible for only a certain
31 versions of an ebuild. For that reason the restrict attribute is in the DTD
33 - The changelog. This probably will be a topic of debate. Initial
34 implementation is not necessary for the herds system to function. The
35 current changelog format though has some problems as the confusion about the
36 format some months ago showed. With including the changelog into XML many of
37 those issues could be resolved. It also would offer possibilities like
38 querying user contributions or things like that.
40 If it is decided to include the changelog into the metadata.xml file,
41 echangelog should be changed accordingly. We further need a conversion tool
42 in both directions. That should not be too difficult though.
44 - Long descriptions. There have been many requests for long descriptions of
45 packages, with inclusion of such a tag in the metadata.xml file this can be
46 done.
48 - Internationalisation. The various descriptions have a lang attribute
49 allowing translated versions. The format of this attribute should be the
50 same as with glibc. One aditional point is that there MUST be a description
51 in English or "C" language.
53 The rationale behind it is that the costs are small, and we would do many
54 people a great favor by allowing this feature.
56 - packages allways have herds, but may also have maintainers. The reason that
57 packages must allways have herds is that maintainers can leave, or have
58 other reasons they cannot maintain a package anymore. We however still need
59 to have someone responsible for the package. In such a case the
60 maintainership falls back on the herd, or herds assigned to the bug.
62 - Multiple herds per package. There are packages that cross boundaries of
63 different categories. An example would for example be a kde p2p client. Such
64 an ebuild should follow the kde style guide, but also should fall to people
65 who are maintaining similar clients. For that reason the primary herd would
66 be p2p and the secondary would be kde. (First one in the file is primary).
68 Thanks for reading this overly long email. I look forward on reading your
69 replies and suggestions, but please do not quote all of my message in the
70 reply.
72 Paul
74 --
75 Paul de Vrieze
76 Researcher
77 Mail: pauldv@××××××.nl
78 Homepage:


File name MIME type
db.metadata.xml text/xml
metadata.dtd text/xml