[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: quilt + dpkg + debhelper: Handling upstream files containing spaces

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.



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.


:-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

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

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?


Thanks for the feedback.

I will do more breeding on it...


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

Reply to: