Merging upstream git history into the debian packaging history?

[Felipe Sateler]

On Sat, Aug 24, 2013 at 2:33 PM, Jonas Smedegaard <dr at jones.dk> wrote:
> Quoting Felipe Sateler (2013-08-24 18:59:03)
>> Hi, I wonder if anybody who has tried the new workflow of merging in
>> the upstream history could share their impressions on it? I'm
>> considering using it, but some questions arise:
>>
>> 1. How to manage stripped upstream taballs? do we not care about
>> shipping upstream code in git that we bother to strip in the debian
>> source tarball?
>
> I only tie upstream git when Free.
>
> Technically it should work fine - you simply end up with a bloated git
> as the stripped parts will end up as a binary blob in pristine-tar.
> Main reason I don't do it is to avoid burdening Alioth with potential
> legal issues.

That sounds reasonable. However, sometimes we strip things that are
distributable, just not free. Not stripping that should not pose any
issues for Alioth.

>
>
>> 2. Managing patches: it looks to me like the new workflow makes it
>> better to make changes directly to the sources (by cherry-picking the
>> appropriate commits/ merging the appropriate debian-specific branches)
>> and setting single-debian-patch in local-options. Has anyone tried
>> this?
>
> I still favor quilt patches - and don't follow how tying our git to
> upstream git renders that inferior: I consider it two separate Worlds -
> one using git and another using tarballs and patch files.

I guess I see the main benefit of the new workflow precisely that the
separate worlds become one. Taking a patch from upstream is as simple
as a cherry-pick, forwarding a patch becomes a pull request of a topic
branch (or committing directly, if one is also part of upstream). My
take is that seeing the debian package as a slightly edited branch of
upstream makes a lot of sense.

If you accept the above premise, then the single-debian-patch option
seems very useful (applied in local-options, so that NMUs don't
break).

>
>> 3. Resolving conflicts between upstream released tarballs and the
>> upstream git repo (possibly due to autogen files). Simply override
>> anything with the contents of the latest tarball? I believe this is
>> what gbp does, but not sure.
>
> Not sure what conflicts you are referring to.

I mean if a file in the tarball is not the same as in the upstream git
repository.

>
> I believe gbp unpacks content, generate a temporary tarball from that,
> do a binary diff against real tarball, and stores diff in pristine-tar
> branch.  Pssobily _missing_ files end up hidden in pristine-tar, while
> added/changed files will cause dpkg-buildpackage error, needing you to
> store the diff as a quilt patch.

I'm not referring to this stage, but at import-orig time. When using
the --upstream-vcs-tag I believe gbp just creates a fake merge between
the tarball and upstream history, preserving the tarball contents. The
procedure looks sane to me, but I was wondering if others saw any
problems with it.


-- 

Saludos,
Felipe Sateler