Definition of Binary field in control file

[Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>]

Hi,

this is the remains of a discussion taken on debian-devel (Packages vs
Sources), which did not provoke any reply in the last couple of days.

I plan to develop this into a policy proposal, but as I feel the issue might
be contentious, I think it wouldn't be bad to announce it so discussion can
start before a formal proposal is send in.

The issue is a violation of the packaging manual in current practice.
The definition of the Binary: field in the control file is:

4.2.10. `Binary'
----------------

     This field is a list of binary packages.

The term binary package is defined quite directly at the very beginning:

     The binary packages are designed for the management of installed
     executable programs (usually compiled binaries) and their associated
     data, though source code examples and documentation are provided as
     part of some packages.

     This manual describes the technical aspects of creating Debian binary
     packages (`.deb' files).  It documents the behaviour of the package
     management programs `dpkg', `dselect' et al.  and the way they
     interact with packages.

Now, current practice is to list *.udeb files in the Binary: field of the
control file, which are not Debian (binary) packages according to Joey Hess,
and don't match the definition above anyway (they are not `.deb' files and
are not processed by dpkg, and they are not provided to be installed on a
normal Debian system)

I think it is not appropriate to simply document current practice, although
this certainly can be done. I think there should be a clean way to
differentiate between udebs and debs (and possibly in the future other files)
build from a source package by looking at the Sources file package entry (or
an equivalent source of information).

I'd prefer to either list udebs in their own control field, for example:

debian-installer-Binary: anna

(The name can be chosen arbitrary). This would provide best backward
compatbility, but would limit this to udebs, and future extensions have to
be exempted again. Or, the syntax could be extended:

Binary: debian-installer/anna

This is not backward compatible, but the inclusion of udebs in the Binary
field was not backwards compatible to begin with. Personally, I like the
debian-installer/anna much better, because it is easily generalizable and
very intuitive.

Any other syntax which specifies debian-installer along with the udeb name
would be nice, any other syntax marking udebs specifically (without
mentioning debian-installer) would only provide a very limited service but
would work, too.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de