Re: native packages
On Tue, Apr 13, 2004 at 03:47:38AM +0200, Rene Engelhard wrote:
> > There are times when the maintainer has made changes (to binary files,
> > for example) which cannot be expressed in a .diff.gz file. Diff
> > doesn't do binary files.
>
> Put them uuencoded into the diff, rm the file in clean and uudecode it
> during build (or backup it and move back)....
And when dpkg-source does that automatically for me when building the
package, and when it also automatically reverses the process when the
source package is unpacked, I'll consider it....
Right now, the first time I find out is when try to build the package,
and it bombs out. And if I have to make a uuencoded blob, then I also
have to modify the debian/rules file to uudecode it, which makes the
debian directory a total mess, just for Debian, and just because some
fanatics (probably the same fanatics who don't do any coding and just
like to wank on and on about evil firmware :-P) are complaining that
they want to see changes upstream. Well, if you want to see the
changes from upstream, you can browse the source repository directly:
http://www.thunk.org:5000/
I should note here that I am both the maintainer and the upstream, so
what typically happens is that very often, when I fix a bug in e2fsck,
I also modify a test filesystem, which is binary blob, to create a
testcase demonstrating that the bug has been fixed. So I am not just
introducing a new binary file, such as an icon; it does happen that I
am modifying an existing binary file. Right now diff.gz just doesn't
work for me in many cases. And no, I am not going to temporarily
create kludge-o-rama's in my debian directory just to deal with with
the fact that dpkg-source is broken with respect to changes in binary
files. I will just simply use a Debian native file format instead,
until I can release a new snapshot release that obviates the need for
changes to binary test cases.
- Ted
Reply to: