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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]