Intent to commit craziness - source package unpacking

[Ian Jackson]

Guillem Jover writes ("Re: Intent to commit craziness - source package unpacking"):
> On Mon, 2016-09-26 at 15:37:19 +0100, Ian Jackson wrote:
> > tl;dr:
> > 
> >  * dpkg developers, please tell me whether I am making assumptions
> >    that are likely to become false.  Particularly, on the behaviour of
> >    successive runs of dpkg-source --before-build with successively
> >    longer series files.
> 
> For format «3.0 (quilt)», that seems fine, to the point I'm fine even
> documenting this, which I can probably do for 1.18.11.

Great.

> For other formats, such as «2.0», I don't think that's true, but I
> assume you don't care about that one anyway. But just mentioning
> because this behavior is probably format-specific. For «2.0» I
> think it could be fixed, and should not be too hard (not sure if it's
> worth it though).

I think the right approach is perhaps to use --skip-patches and
--before-build only with 3.0 (quilt).  The that would leave 2.0 (or
other strange or future formats) producing a correct (although
possibly sub-optimal) import.

> > dpkg-source does not currently provide interfaces that look like they
> > are intended for what I want to do.  And dgit wants to work with old
> > versions of dpkg, so I don't want to block on getting such interfaces
> > added (even supposing that a sane interface could be designed, which
> > is doubtful).
> 
> Even then I'm still interested in a decription of what you'd need
> ideally, to take into account when having a pass at cleaning up that
> part of the interface. I think you could be interested in a cleaner
> Dpkg::Source::* hierarchy, for the mid/long-term?

For `3.0 (quilt)' explicit interfaces for applying and unapplying
individual patches would help.  But really IMO such an interface ought
to be exposed on the command line rather than (or as well as) via a
Perl module.

Beyond that I find it hard to see what could make dgit's life easier.
Since dgit wants to construct a commit graph representing the source
package's innards, unless dpkg-source explicitly provides an interface
along those lines ("please output a graph of unpacked source tree
states and corresponding commit messages") dgit is still going to have
to know specially about most of the source package formats.

> > * dgit will untar each input tarball (other than the Debian tarball).
> > 
> >   This will be done by scanning the .dsc for things whose names look
> >   like (compressed) tarballs, and using the interfaces provided by
> >   Dpkg::Compression to get at the tarball.
> 
> Hmm, Dpkg::Source::Archive is currently private, but I might have a
> look at making it public if that would be helpful here.

I think the amount of logic I would have to replicate is minimal.

> > * As currently, dgit will take steps so that none of the git trees
> >   discussed above contain a .pc directory.
> 
> As long as the directory does not disappear from the working tree,
> that should work.

Right, indeed it won't.

Thanks for your comments.  I feel unblocked :-).

Ian.

-- 
Ian Jackson <ijackson at 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.