On Fri, Apr 2, 2010 at 11:03 PM, <[email protected]> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
