Re: RFS: flint -- C library for number theory
Hi Julien.
i see your points. let me try to clarify things a bit. sorry if i am
annoying the other receipients.
On Sun, Aug 10, 2014 at 10:53:10PM +0200, Julien Puydt wrote:
> (1) the manpage says git-dpm uses a "patched" branch, and I don't see it in
> "git branch -a"
the patched branch is accessible with 'git-dpm checkout-patched'.
pushing it to the public repo is unnecessary/redundant (and harmful, as
someone might expect it to retain history). once the package is ready,
you may use "git-dpm tag" to add a shiny immutable tag to it.
> (2) git-buildpackage is happy with the current packaging
because it doesn't seem to care about how patches are organized.
> (3) pristine-tar has no problem checking out upstream tarballs
dito.
> (4) we're discussing for a single patch which is going away in the next
> version
it's about whether the patch has been committed to the packaging branch
or to an upstream+patched branch. maybe you know how to rebase a
missorted patch to a new upstream version. i don't. git-dpm doesn't
know, and presumably git-buildpackage is not meant to do such things.
(yes, there is gbp-pq, and i admit that i do not understand how it is
supposed to work. my guess is, it cannot rebase in this situation
either).
the patch in question appears to be a cherry-pick from future upstream,
so it has been a git commit from the beginning. git will know how to
rebase it back to upstream.
> (5) I can't help but notice that git-dpm complains about two files
> containing non-debian change... and one of them is fmpz/test/t-invmod.c
> which is pristine upstream!
fmpz/test/t-invmod.c has been edited in 90b70c2cce, a commit to the
master (packaging) branch. this is the whole trouble.
> I really have the impression that only git-dpm is unhappy with my package,
> and that the only reason why it's complaining is that I don't use it. It
> would be nice to use it, but (4) says it might be quite overkill, and (5)
> says git-dpm is going to make it hard, since it won't even recognize
> pristine upstream for what it is.
you do not have to use git-dpm to not commit upstream changes to the
debian branch. i don't see how the total number of patches changes this
or how git-dpm is making it any harder.
> So, what should I do?
1 revert the commit in question
2 commit the change on top of the upstream branch
3 merge the patched upstream branch into master
4 update debian/patches
it doesn't matter much if you use git-dpm or not. doing things manually
is just a bit more involved. for example
2 find the current patched branch... (here: just take upstream and
forget about that one patch)
3 what was the right strategy option again? -srecursive -Xtheirs. maybe
4 git show will show your commit, but will the format be ok? don't
forget to update series.
independendly, you may want to plough debian/.git-dpm. expect some
questions from a clueless about how to do stuff without git-dpm...
cheers, hth
felix
Reply to: