Definition of Binary field in control file
- To: email@example.com
- Cc: Jeff Bailey <firstname.lastname@example.org>
- Subject: Definition of Binary field in control file
- From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
- Date: Sat, 21 Apr 2001 23:48:29 +0200
- Message-id: <20010421234829.C749@ulysses.dhis.net>
- In-reply-to: <20010419213223.A343@ulysses.dhis.net>; from Marcus.Brinkmann@ruhr-uni-bochum.de on Thu, Apr 19, 2001 at 09:32:24PM +0200
- References: <20010416201229.I345@ulysses.dhis.net> <3ADB9128.D88172BD@optushome.com.au> <20010417234938.A397@ulysses.dhis.net> <20010418020932.C5514@debian.org> <20010418175225.A354@ulysses.dhis.net> <20010419131932.C1123@azure.humbug.org.au> <20010419162700.A347@ulysses.alg.ruhr-uni-bochum.de> <20010420010204.A15790@azure.humbug.org.au> <20010419213223.A343@ulysses.dhis.net>
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:
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:
(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:
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
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.
`Rhubarb is no Egyptian god.' Debian http://www.debian.org email@example.com
Marcus Brinkmann GNU http://www.gnu.org firstname.lastname@example.org