> > But it needs lots of work. > > Could you answer these questions on the future of dpkg-source for me:
> > 1) How do you propose modifying dpkg-source for handling additions > > of binary files to Debian packages (without uuencoding them)? > > I don't know about Ian, but I suspect a relatively simple way would be to > have dpkg-source read a list of binary files, and handle those > differently. > > *Modified* binary files are a little harder, but there are several options > how to handle those - at worst, dpkg-source could uuencode those itself. Note, that I don't mind at all that dpkg-source makes it harder for me to include additions of binary files to Debian packages. Idealy, you should never add a binary file to a debian package, but rather add the *source* of that binary file, be it a c-sourcefile, an xfig script that created the .jpeg picture you added, or whatever. Whenever there is a "real" sourcefile for a binary, the maintainer should go to great lengths to include that, and make sure debian/rules creates the intended binary (as with the .jpeg picture, it's much easier to include just the .jpeg picture, but you really should include the .fig source, create the .jpeg in debian/rules). Yes, I realise that sometimes, there simply isn't a real source. For example, debian-doc might carry a .wav of Ian Murdoc saying "debian". In those cases it should be possible to include binary files. But I rather like it that debian-source makes it more difficult to include binary files, and don't even mind that the maintainer has to resort to uuencode to include them: it should only be used as a last resort. -- joost witteveen, [EMAIL PROTECTED] My spamfilter is so good, it correctly catches 90% of incoming spam, *including* all email from my PhD supervisor.
