Hi Ian,, On Mi 09 Jan 2019 16:13:57 CET, Ian Jackson wrote:
Mike Gabriel writes ("quilt + dpkg + debhelper: Handling upstream files containing spaces"):I am currently working on OpenBoard packaging. OpenBoard ships loads of embedded jquery.* copies of code (and other JS libs, too). Those jquery.* et al. files are in folder paths that contain blanks. Ouch. It seems that our tool chain components fail completely on handling them. Or maybe I am doing entirely wrong.Grlgk.
:-)
I worked around this issue with [1]: Rename the folders that contain blanks and the dh_link works ok. Unfortunately, those folder names get displayed ot the user in the OpenBoard UI. Yes, that's faulty by design, but that's not with this mail is supposed to be about.Nglgkkrgl.
:-D (grin...)
I don't have any other perfect suggestions, but I do have a suggestion is IMO tolerable and which you may find less bad than other approaches: * Use the 1.0 native source package format. Ie, no orig tarballs, use one tarball, like you would for a Debian-native package. (You may need to override an overzealous lintian warning.) * Use one of `git merge' or `git debrebase' to manage your delta from upstream. (Disclosure: I wrote `git-debrebase'.) These tools can work with your delta entirely in git and will not be troubled by the spaces in the filenames. Then you do not need to represent the changes you make as patch files suitable for diff. With git-debrebase you can even continue to separate your changes out into a `patch queue': a rebasing linear series of commits (git-debrebase calls it a `delta queue' because they're not patches then). With either of these approaches you can no longer publish the delta queue as a series of patches - but you can't really do that anyway, since even with your other approaches part of your delta is a repacking phase. The other downside of this approach is that you need to re-upload the whole upstream source code with every Debian upload. I'm not sure how big your upstream source is. If it is big, then this is not a good approach.
The source package is 20M+ big. Not really big, but not really small, either
I do have an idea how to fix this: a source package format `3.0 (rsync)', which could represent any delta. But that project is stalled at a conceptual stage, mostly due to the need to support existing ftpmaster workflow :-/.
So this is mere theory, so far. Right?
Regards, Ian.
Thanks for the feedback. I will do more breeding on it... Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
Attachment:
pgpq04xOrE7iG.pgp
Description: Digitale PGP-Signatur