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

Re: DEP 12: Per-package machine-readable metadata about Upstream

On Thu, 2013-01-03 at 10:29:13 +0800, Paul Wise wrote:
> On Thu, Jan 3, 2013 at 9:11 AM, Charles Plessy wrote:
> >  The source package control files and some of their derivatives are currently
> >  used to document the URL of the home page of the work that is packaged
> >  ("upstream").  However, this approach is hard to extend to other information
> >  describing upstream, because the size of the control files has to be limited
> >  according to the limited power of some systems running Debian.
> This DEP-12 seems to exist because of this assumption. Is it true that
> everything from debian/control must end up in the Packages files?

Not really, there are different stages where this gets decided. There's
the user defined fields in debian/control with their explicit export
rules, there's dpkg-gencontrol which has its own defaults, then there's
the archive generation software (dak in Debian's case). So a field could
be shipped in a binary(.deb)/source(.dsc) package but still be excluded
from a repository index (Packages/Sources), or placed in a different
index file (Upstreams) on the archive side, for example.

We could also modify for example where dpkg-gencontrol retrieves its
information, to add as a source debian/upstreams in addition to
debian/control, but first we'd need to see if this is desriable or if
it makes sense at all (but definitely not if that file is in YAML).

> >  We propose a new file in the source packages, debian/upstream, formatted
> >  in YAML to hold arbitrary information about upstream, for instance the
> Is there any reason you didn't choose a deb822 based format?

I already mentioned my dissatisfaction with that on the last iteration
of this proposal, and I still think it's a very poor choice of a format
given our current tools and “unified metadata format”. But no specific
reasons were given AFAIR.

> >  The scope of this DEP is the format of the debian/upstream file, and the
> >  specification of the most frequent fields.  The flow of information from the
> >  source packages to data providers such as the UDD are is specified here.
> >  Please refer to http://wiki.debian.org/UpstreamMetadata for more information
> >  on that subject.
> Some further thoughts:
> debian/upstream is to contain a Homepage, should we move the Homepage
> from debian/control to debian/upstream and thus out of Packages?

I guess we could have a discussion about the possibility/advantages of
having one index file (ex. Packages) containing exclusively machine
consumable metadata (for package managers), to favour small/embedded
systems, and another one with user consumable metadata. Because these
could be recombined by high-level package managers if desired, think
the distinction between apt and aptitude for example, or apt with an
option. The first fields that come to mind could be Homepage,
Maintainer and Description (and for the latter this has already happened
somewhat). But then this does not require a split in the source format,
but only in the archive indices, and possibly in the package managers


Reply to: