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

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



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.


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.

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

Regards,
Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.


Reply to: