Re: correctly upgrading a package's source format to 3.0(quilt)

[jmroth+deb@iip.lu]

Well, let's first speak in general terms:

The facts are that .orig files should be UNMODIFIED upstream archives,
and unless really necessary (whatever that means), should only be
modified by patches (debian/patches), so that the modifications made
to upstream are transparent to every package maintainer.

Also, performing repackaging INSIDE debian/rules should be avoided, I
guess.

Those two facts limit what one can do (dynamically/programmatically)
to a package.

Correct me whenever you feel I got something wrong.

Now consider this real-world example:
dpkg-source complains upon extracting some .orig-<component>.tar.gz
that there are files without final newline. Now: what would be the
most correct way to go about this? From the reasoning above, by
creating a patch, I guess.

While that would be possible, even though the patch has to be
regenerated for each new upstream version of everything, what do I do
when it becomes necessary to keep a file from upstream unmodified, but
when I still want to add a modified copy to the package (e.g. modified
database schemas for several use cases)? I guess I just need some sort
of "maintainer patches" ready, and apply them manually when packaging
a new version, and just include the modified file in the debian/
folder from where it is installed via the standard mechanisms.

As a second example: deleting/not installing unwanted files:
- I could repackage without those files.
- I could repackage dynamically (do magic in debian/rules) to create
build directories without those files.
(We excluded those two possibilities above already.)
- I could simply choose not to copy those files to the build
directory, but hey, since I'm mostly copying entire folders over there
using dh_install and the package.install file, I would have to put
instructions for every single file in there - this is not practical.
- I can NOT simply remove the files from the extracted .orig archives,
because on the next debuild run it would bark out that they could not
be removed because they were already removed before. Sure, I could
check for their presence before trying to remove, but still, this does
not seem to be a clean way.
- I could first copy everything to the build directories and then
delete specific stuff from there, like so:

install:
	dh install
	rm debian/package/stuff

%:
	dh $@

But then, what would be the difference between creating a patch that
removes the stuff initially, and doing this. It's probably only a
matter of taste.

For some things, it is just not clear what to do and mainly /when/. I
guess that comes with time and experience.

JM