[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: What is the best place for package meta-data ?

On Wed, Aug 5, 2009 at 12:47 PM, Charles Plessy<plessy@debian.org> wrote:

> I think that you asked the key question, and that the answer will help us to
> sort out the metadata contents in Debian packages.
> Currently, debian/control contains:
>  - Informations for the package manager (dpkg). For instance, the package name,
>   the build dependancies, the binary dependancies, the Essential field,…
>  - Informations for the archive manager (apt). For instance, the section and
>   the priority, the package description,…

I'd put the package description in a "user" category or just its own category.

>  - Informations for the online user. For instance the homepage and VCS URLs.

I'd put the homepage in a "user" category and the VCS URLs in a
"developer" category.

> Typically, informations for the archive manager that are provided by a package
> repository can differ from the contents of the source package. Descriptions can
> be translated, section can be overriden (the Section: field in the source
> package is not authoritative), Debtags can be added, …
> Informations for the online user could follow the same logic: a copy could be
> included in the source packages, for the benefit of providing it in a central
> place and to give an easy interface to the package maintainers, but the one
> that the users get on-line could be refreshed independantly of package uploads.
> I was thinking to propose to have a supplementary file in the debian directory
> following the ‘Name: contents’ convention of Debian control files (same as YAML
> if we do not do wrapping), that maintainers could update in the source
> package’s VCS (or at worse on their local hard drive) and use to push the
> meta-data in a central database between two uploads if need is.
> However, I realised that the Ultimate Debian Database, which I thought would be
> a nice place to host the data, works on a retreiving model rather than a
> pushing model. Before elaborating a complex workaround involving an
> intermediate place where maintainers could push their meta-data, does anybody
> think about an alternative? Andreas Tille suggested me the Package Entropy
> Tracker, but it would limit the system to packages hosted in a Subversion
> repository. This said, since many of the packages that caused us dig that
> question (software for which we would like to provide registration and
> bibliographic information) are mostly stored in a Svn, that may not be a
> blocker for making a poof of principle…

It seems to me that all this metadata we have about packages, the
canonical location for it is dak's database on ftp-master, the
Packages/Sources files are generated from there.

The data in that database is gathered from .changes files and binary
and source packages uploaded to ftp-master, except for debtags and
translated descriptions (IIRC, not sure how those get in). Re-using
that workflow for meta-data updates, say, by uploading metadata
updates in .changes files instead of full packages could be useful.

How to split up the Packages/Sources files into more granular pieces
would be nice, but which fields should go into which sets needs
defining, and which set of sets should be the default. For
compatability, it could continue to generate Packages/Sources as they
are and add Packages-Homepage, Packages-dpkg, Packages-user etc files
for updated apt/dpkg to use, allowing us to avoid waiting a whole
release cycle to use this stuff.



Reply to: