[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Forwarded: RFC: New source packaging format



> > 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, joostje@debian.org

My spamfilter is so good, it correctly catches 90% of incoming spam,
*including* all email from my PhD supervisor.


Reply to: