Intent to commit craziness - source package unpacking
Ian Jackson
ijackson at chiark.greenend.org.uk
Thu Sep 29 16:59:04 UTC 2016
Guido Günther writes ("Re: Intent to commit craziness - source package unpacking"):
> Hi Ian,
Hi, thanks for your attention.
> 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.
Ah. You have spotted a bug in my proposed algorithm, which is that it
would include the successive changes to the series file in the
per-patch commits. That was not intentional and I will make sure my
actual generated commits don't look like that.
> 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.
Excuse me if I digress into some background. You may know all this
but if you don't you may become confuse:
There are two relevant parts of the gbp/dgit workflow: let's call them
"push" and "pull-dsc-import".
"push" is where a gbp-using maintainer (or someone with an appropriate
maintainerish hat like a QA uploader) uses "dgit --quilt=gbp push".
In this case, dgit will produce a dgit-compatible patches-applied
branch out of the patches-unapplied tree provided by the user. This
is done by actually calling gbp pq import. The resulting branch is
`private' in the sense that it is published to the dgit server, but
not left on the maintainer's own branch.
(There is a wrinkle with .gitignore. If the maintainer edits an
upstream gitignore, gbp's default behaviour is to exclude those
changes from the source package upload. This is not compatible with
dgit's model; so in this case dgit will generate a new patch to
represent the .gitignore changes. There will be a new commit on the
dgit view branch which adds that patch and the corresponding series
file entry.)
The "pull-dsc-import" case is where a gbp-using maintainer deals with
an upload done by someone else who didn't use dgit push.
The gbp-using maintainer does not need to use dgit for this. If they
like, they can import the source package however they did this before
dgit came along. The resulting maintainer branch can then be used
with "dgit --quilt=gbp push" just as before, although depending on the
git history the maintainer built, the maintainer might need to say
"dgit --overwrite --quilt=gbp push" to reassure dgit that the
maintainer is intentionally replacing the version in the archive.
However, I think dgit could make this easier for the maintainer. If
the maintainer uses "dgit fetch" it will fetch the source package from
the archive and convert it to a git branch. That is the "dgit created
history".
Right, that's the end of the background.
This history will (usually) have a pseudomerge at the top, making it
fast forward from the dgit view branch generated during the
maintainer's last "dgit push".
Then (looking deeper into the history) it will have the dgit-generated
patch commits, one for each patch. (Maybe there will be the
.gitignore patch on top of those - see above.) These commits will in
fact NOT touch anything in debian/.
Then will be the base commits for the tarballs and the debianisation.
Graphically:
dM pseudomerge
,'|
,' |
,' dM final patch u/s only
,' |
<archive/debian/X] ,' dM some patch u/s only
pseudomerge dm .....
,'| dM first patch u/s only
,' | |
,' | dM Debianisation creates[1]
,' | | debian/*
,' | |
,' | dM Upstream [2] creates u/s[1]
previous |
dgit view |
history dm .gitignore fixup d./patches/*
[3] | (create patch to only
| create /.gitignore)
|
dm apply final patch us/only
|
dm apply some patch us/only
.....
dm apply first patch us/only
|
|
<debian/X] m final patch made by maintainer
/|\
[whatever]
Commits made by:
m - maintainer before previous push
dm - maintainer's dgit during previous dgit push
dM - maintainer's dgit during dgit fetch; constructed from
non-dgit-pushed source package
(Here "maintainer" means someone using gbp and sharing history with
the other maintainer(s).)
[1] Of course if the upstream contains a debian/, then that will be
present in the upstream tarball and will be replaced in Debianisation.
[2] Mostly, imports of the same u/s tarball will generate the same
commit, so this commit might be the ancestor of a previous non-dgit
upload.
[3] Usually the previous dgit view history will have been made by the
maintainer's dgit from previous maintainer dgit pushes, in which case
it will have as ancestor previous maintainer views.
There is another possibility, which is an NMU made with dgit, by an
NMUer who isn't using gbp. (For these purposes again, a
"non-maintainer" is someone who is not using gbp and isn't sharing git
history with the maintainer(s).) I'm going to illustrate work done by
someone who restricts themselves to the kind of minor changes an NMUer
might expect to make in Debian:
<archive/debian/Y]
dn NMUer's upstream
| changes made d./p./*
if there | into patch(es) d./p./series
are multiple | maybe multiple
NMUs this may | patches created
be repeated |
n NMUer's git commit
| maybe changes to any
| u/s files, maybe not (mixed)
...
n NMUer's git commit
| maybe changes to any
| u/s files, maybe not (mixed)
|
<archive/debian/X] |
pseudomerge dm
,'|
,' |
,' |
,' dm .gitignore fixup d./patches/*
,' | (create patch to only
,' | create /.gitignore)
previous |
dgit view dm apply final patch us/only
history |
[3] dm apply some patch us/only
.....
dm apply first patch us/only
|
|
<debian/X] m final patch made by maintainer
/|\
[whatever]
Commits made by:
m - maintainer before previous push
dm - maintainer's dgit during previous dgit push
n - NMUer, directly, using git commit or whatever
dn - NMUer's dgit during their dgit push
[3] as before.
> > 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.
I'll send you an example.
> 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 )
I had a look at what gbp pq made out of some of the commits in some of
my tests and was surprised to see it dropping the commit messages.
I see there's another mail from you which I will go and read now...
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.
More information about the vcs-pkg-discuss
mailing list