Randy Sims is also interested in the metadata project, and I think we should be able to produce a metadata spec module sometime soon. Sorry to shoot my mouth off at CPLAN and produce nothing on it.
He independently/heroically came up with some revisions to the spec at
http://module-build.sf.net/META-spec-new.(pod|html) , and we plan to merge these with the decisions that were made at CPLAN, and then instantiate them in a module.
Maybe something to think about: I think it would be wise to sanity check our
spec against at least two out of the three: Debian, NetBSD, Gentoo. These are
all systems I know have a good working module description system. Our metadata
should be at least as powerful as theirs.
Debians control files look something like:
Source: gentoo
Section: x11
Priority: optional
Maintainer: Josip Rodin <[EMAIL PROTECTED]>
Build-Depends: debhelper (>> 3.0.0), xlibs-dev, libgtk1.2-dev, libglib1.2-dev
Standards-Version: 3.5.2
Package: gentoo
Architecture: any
Depends: ${shlibs:Depends}
Suggests: file
Description: A fully GUI configurable X file manager using GTK+
gentoo is a file manager for Linux written from scratch in pure C. It
uses the GTK+ toolkit for all of its interface needs. gentoo provides
100% GUI configurability; no need to edit config files by hand and re-
start the program. gentoo supports identifying the type of various
files (using extension, regular expressions, or the 'file' command),
and can display files of different types with different colors and
icons.
.
gentoo borrows some of its look and feel from the classic Amiga file
manager "Directory OPUS" (written by Jonathan Potter).The only thing really interesting is this section in the manual:
* Depends:
The package will not be installed unless the packages it depends on are installed. Use this if your program absolutely will not run (or will cause severe breakage) unless a particular package is present.
* Recommends:
Frontends such as dselect or aptitude will prompt you to install the recommended packages along with your package; dselect will even insist. dpkg and apt-get will ignore this field, though. Use this for packages that are not strictly necessary but are typically used with your program.
* Suggests:
When a user installs your program, all frontends will likely prompt them to install the suggested packages. dpkg and apt-get won't care. Use this for packages which will work nicely with your program but are not at all necessary.
* Pre-Depends:
This is stronger than Depends:. The package will not be installed unless the packages it pre-depends on are installed and correctly configured. Use this very sparingly and only after discussing it on the debian-devel mailing list. Read: don't use it at all. :-)
* Conflicts:
The package will not be installed until all the packages it conflicts with have been removed. Use this if your program absolutely will not run or will cause severe problems if a particular package is present.
* Provides:
For some types of packages where there are multiple alternatives virtual names have been defined. You can get the full list in the /usr/share/doc/debian-policy/virtual-package-names-list.txt.gz file. Use this if your program provides a function of an existing virtual package.
* Replaces:
Use this when your program replaces files from another package, or completely replaces another package (used in conjunction with Conflicts:). Files from the named packages will be overwritten with the files from your package.
I haven't looked at RPM and others yet, but it's a good idea.
I have also looked at Ruby's package system, RubyGems <http://rubyforge.org/projects/rubygems/> (Why don't we have a perlforge?) I talked briefly with the authors. While they too use YAML for recording metadata, they were not really interested in working together on a single specification. What they have is not even as mature as that in the original META.yml spec. I've been meaning to take a look at the python camp to see what there doing, but haven't had a chance yet.
I'm already starting to forget what we discussed... :-) Did we talk about having any of the more free-form fields like the basic "description" being in languages other than English?
Regards, Randy.
