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 <ijack...@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@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss > _______________________________________________ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss