Hi,
On Fri, 23 Aug 2013, Ian Jackson wrote:
> The thing that really bothers dgit is that it is not always possible
> to round trip a tree through dpkg-source. (And the case where it
> doesn't work is the common one.)
>
> That is, if I do this:
> 1. dpkg-source -x
> 2. edit things
> 3. dpkg-source -b
> 4. dpkg-source -x on the output from stage 3
> then the output of step 4 is not always the same as the input
> to step 3. Typically the output of step 4 has additional metadata
> files inside the tree.
Well, by default step 3 fails if you have upstream changes. Unless you
use --auto-commit or --single-debian-patch. So the logical thing to do
is to call "dpkg-source --commit . <patch-name>" when you know that you
have upstream changes compared to the last debian package.
I believe that after the --commit you have the same metadata that you
would have after step 4.
> For some more sophisticated workflow, it is necessary to round trip
> the patch stack through the archive and back into git.
I'm not following you here. Can you elaborate ? ("round-trip through the
archive" doesn't mean anything obvious to me)
What I would like to have with "3.0 (quilt)" source packages is a git
repository with the patches applied but without the .pc/ quilt dir (that's
just noise). We would probably have a debian/source/local-options to
indicate to dpkg-source that the patches are already applied and that
it should deal with it.
Then I add commits like usual and they would be automatically
converted to new quilt patches in a later step when I tell dgit
to build the source. (Bonus point: we could add some metadata
in commit notices to merge the change in a existing quilt patch)
The really tricky part is how to update the patches when you merge
a new upstream version that changes the underlying code so that the
patches no longer apply. See http://bugs.debian.org/572204 for how Colin
Watson deals with this. I think he uses bzr and I'm not sure if we
can force git to proceed with the merge if we have local uncommitted
changes.
Basically, it would be good enough I believe if we can approximate this
with:
1/ a commit that reverts the Debian patches
2/ a commit that merges the upstream changes + reapplies Debian patches
(git merge --no-commit + quilt push -a with the required human fixes)
Bonus point if your replace the "quilt push -a" with git cherry-pick of
all patches and automatic refresh of the patches.
> > BTW, instead of advising against "3.0 (quilt)" you should rather recommend
> > the usage of the --single-debian-patch option when using that format...
> > this will make it mostly work like "1.0".
>
> This is a command-line option ? How does one specify in the source
> package that this is to be used.
You put "single-debian-patch" in debian/source/local-options (or …/options
if you want to keep it in the generated source package).
(=> with "local-options" this is another case of something that you can
have in your tree and that you won't have in the unpack of the generated
source package)
> > - what/who creates the initial repository? and what/who keeps it in sync
> > with
> > the (non-dgit-based) archive uploads?
>
> The repos are created only by dgit users. Different dgit users see
> the same commits from the archive: the synthesised commits are
> deterministic.
OK, assuming that they are created on top of the same commit I guess.
Are those commits replacing all the files or are they actually a merge of
changes from upload_n-1 to upload_n in the git repository?
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130823164508.gc30...@x230-buxy.home.ouaza.com
