Intent to commit craziness - source package unpacking

[Guido Günther]

Hi Ian,
On Wed, Sep 28, 2016 at 11:09:03AM +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: Intent to commit craziness - source package unpacking"):
> > Thanks for your comments.  I feel unblocked :-).
> 
> So, I now intend to go and implement my plan.
> 
> There will be a little while (perhaps a few weeks) before I am in a
> postion to release this in dgit 2.0.  But after I do that, I will not
> want to change the import algorithm again: it is important that the
> imports be as stable as possible.
> 
> So now would be a good time for maintainers of git packaging tools (eg
> git-dpm and gpb) to have an opinion about the detail of the generated
> pseudohistory - in particular, the detail of the commits generated
> from the `3.0 (quilt)' dpkg-source patches.

>From what I understand the format to produce is not compatible in what
"gbp pq" currently expects, that is just one commit per patch without
any chnages to other files in debian/ (like the series file). 'gbp pq'
is just a helper for handling the quilt patches, not more.

I don't understand yet how you expect the actual workflow between gbp
and dgit to look like but I would be happy to have a look at a prototype
dgit created history. I can e.g. imagine telling "gbp pq" to filter out
chnages in debian/ during patch creation.
 
> Also, I would welcome suggestions for what kind of compatibility test
> I could perform on such a series of commits.  dgit has an extensive
> test suite (advertised via autopkgtest) which would be well-suited to
> such a compatibility test.
> 
> An example of such a tree might be, "split out the patch queue part of
> the git pseudohistory and feed it to gbp-pq, asking gbp-pq to
> regenerate the source package, and expect the output to be identical
> to the original input source package".  Guido, if I get the
> preconditions right, should I expect such a test to pass ?  Is there a
> risk it would break in the future due to changes in gbp-pq's
> conversion algorithm ?

It would be nice to have "gbp pq" reproduce debian/patches identically
on such a tree but I would rather have a look at how the dgit created
history finally looks once you implemented it. gbp-pq's conversion
algorithm is not expected to change (at least in the default
configuration, I have some other ideas about patch handling but that
would not modify the current workflow ).
Hope that helps,
 -- Guido

> I confess that I am less familiar with git-dpm.  I don't know what I
> should be thinking about to try to make the output most useful to
> git-dpm users.
> 
> (I also don't know whether the goals of helping git-dpm users and
> gbp-pq users, and potentially users of any other tools, are in
> conflict.
> 
> It would be annoying if these tools would disagree about the best form
> of import of a particular patch queue: the import algorithm should be
> the same for different dgit users, so I wouldn't be able to make this
> a per-user configuration option and would have to choose..)
> 
> Thanks,
> 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.
> 
> _______________________________________________
> vcs-pkg-discuss mailing list
> vcs-pkg-discuss at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
>