Re: native packages
Theodore Ts'o <email@example.com> writes:
> 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:
> I should note here that I am both the maintainer and the upstream, so
Then just make a new upstream release.
> 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