Re: Entries in Packages files that lack a Source field

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

Anthony Towns <aj@azure.humbug.org.au> writes:

> Adeodato Simó wrote:
>>   As you probably know, entries in the Packages file only have a Source
>>   field if the name of the source package is different from the name of
>>   the binary package being described. This is an inconsistency that makes
>>   it a bit harder to massage this data, e.g. with grep-dctrl.
>
> Why not add a patch to grep-dctrl instead?
>
> Cheers,
> aj

And have it insert Source: ... entries into debian/control files?

grep-dctrl does not want to have special knowledge about the data
content of what it greps but is ment to work on anything resembling
RFC822 headers. So while it would be possible to teach grep-dctrl
about Packages files and add Source: ... lines it is not desireable.

There is also another reason for more Source: ... entries in the
Packages file mentioned in an unrelated thread earlier and also a
reason why grep-dctrl can't rebuild that entry:

The detection of binary NMUs is currently, among others, using the
debian version of a package and guessing from its form. What is a
binary NMU and what not is not aparent from the Packages file. It has
been suggested to insert Source: entries pointing to the original
source of an binary NMU instead.

Examples:

Packages:
 Package: fftw-dev
 Architecture: m68k
 Source: fftw
 Version: 2.1.3-16.0.1

 Package: libcnumx0
 Architecture: m68k
 Source: numerix
 Version: 0.19-5.1.1

Sources:
 Package: fftw
 Binary: fftw2, fftw-dev, fftw-docs, sfftw-dev, sfftw2
 Version: 2.1.3-16

 Package: numerix
 Binary: libnumerix-ocaml-dev, libcnumx0-dev, numerix-doc, libnumerix-ocaml, libcnumx0
 Version: 0.19-5.1.1


What should grep-dctrl do there? Guessing that -x.y.z is an binary NMU
or not? Either way one of them will be wrong.

MfG
        Goswin