[gentoo-dev] IMPORTANT: The proposal for the metadata.xml file

[Paul de Vrieze]

First let me introduce the context of this proposal.

This proposal is a vital step in making herds work. This proposal proposes the 
format of the metadata file. This proposed file is the result of a process in 
which a number of developers where involved. Before implementing metadata 
files, we want some extra input, and I will make sure that this input is 
taken into account in the final format.

I would like the input from all of you on the files. Note that metadata.dtd is 
the most important one, and db.metadata.xml is an example for the sys-lib/db 
package, that shows some of the features of the dtd. The example is not meant 
to be exhaustive, though.




Below I will write out the reasons for certain choices that have been made. I 
have also put in http://cvs.gentoo.org/~pauldv/metadata-2003.05.26.log and 
IRC log of a discussion of 26 May with me, absinthe, drobbins, danarmak and 
others on this topic.

- We need to have herds. For that we need to be able to assign packages to
  herds. While we first thought a MAINTAINER file was enough, through
  discussions we found that there is more information we want to have about a
  package, and that we are probably going to want to add more even later on.
  For this XML was chosen as an implementation format for this file.

  There must be rather strong arguments against it to let go the choice of XML

- We need ways to have people or herds only responsible for only a certain
  versions of an ebuild. For that reason the restrict attribute is in the DTD

- The changelog. This probably will be a topic of debate. Initial
  implementation is not necessary for the herds system to function. The
  current changelog format though has some problems as the confusion about the
  format some months ago showed. With including the changelog into XML many of
  those issues could be resolved. It also would offer possibilities like
  querying user contributions or things like that.

  If it is decided to include the changelog into the metadata.xml file,
  echangelog should be changed accordingly. We further need a conversion tool
  in both directions. That should not be too difficult though.

- Long descriptions. There have been many requests for long descriptions of
  packages, with inclusion of such a tag in the metadata.xml file this can be
  done.

- Internationalisation. The various descriptions have a lang attribute
  allowing translated versions. The format of this attribute should be the
  same as with glibc. One aditional point is that there MUST be a description
  in English or "C" language.

  The rationale behind it is that the costs are small, and we would do many
  people a great favor by allowing this feature.

- packages allways have herds, but may also have maintainers. The reason that
  packages must allways have herds is that maintainers can leave, or have
  other reasons they cannot maintain a package anymore. We however still need
  to have someone responsible for the package. In such a case the
  maintainership falls back on the herd, or herds assigned to the bug.

- Multiple herds per package. There are packages that cross boundaries of
  different categories. An example would for example be a kde p2p client. Such
  an ebuild should follow the kde style guide, but also should fall to people
  who are maintaining similar clients. For that reason the primary herd would
  be p2p and the secondary would be kde. (First one in the file is primary).

Thanks for reading this overly long email. I look forward on reading your 
replies and suggestions, but please do not quote all of my message in the 
reply.

Paul

-- 
Paul de Vrieze
Researcher
Mail: pauldv@××××××.nl
Homepage: http://www.devrieze.net