Re: correctly upgrading a package's source format to 3.0(quilt)
On Fri, Apr 2, 2010 at 11:03 PM, <jmroth+deb@iip.lu> wrote:
> Also, performing repackaging INSIDE debian/rules should be avoided, I
> guess.
Actually a debian/rules get-orig-source target is one of the more
common ways to repack the upstream source to create an orig.tar.gz
where nessecary. There are very few valid reasons to repack though:
http://www.debian.org/doc/developers-reference/best-pkging-practices.html#repackagedorigtargz
> 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.
Too minor to warrant any change in Debian, I'd suggest pushing the fix
upstream and waiting for a new release.
> 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.
Ship the patch in debian/patches/ but don't include it in
debian/patches/series. Then at build time copy the file and manually
apply the patch. I do wonder why this patch is nessecary but hasn't
been accepted upstream though.
> As a second example: deleting/not installing unwanted files:
Another option is to send upstream a patch to not install those files
or to not install those files when a certain configure option is set.
> - I could repackage without those files.
Unless they are not DFSG-free, don't do this.
> - I could repackage dynamically (do magic in debian/rules) to create
> build directories without those files.
> (We excluded those two possibilities above already.)
That would be acceptable, but I imagine the upstream build system will
barf when it tries to install the files that you removed early in
debian/rules build or debian/rules install.
> - 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.
package.install files allow wildcards if that helps. Also dh_install
has an --exclude option.
> - 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.
rm -f doesn't care if the files exist or not.
> - I could first copy everything to the build directories and then
> delete specific stuff from there, like so:
I would do this (with dh7):
override_dh_install:
dh_install --exclude=bar --exclude=baz
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: