Merging upstream git history into the debian packaging history?

[Jonas Smedegaard]

Quoting Felipe Sateler (2013-08-26 00:09:49)
> 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.

True.  I just choose to tie upstream git only when not repackaging, to 
keep things simple.


> >> 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).

Ok.  We then do not value tarballs and patches the same.


> >> 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.

I have not seen a problem in that (and yes, I believe I have tried, even 
if it is not my preferred style as mentioned in the beginning), because, 
as I understand it, when using *both* --upstream-vcs-tag *and* providing 
a tarball, it will do the right thing (as I tried to explain above but 
failed: perhaps just read the documentation).


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20130826/b5ad224f/attachment-0001.sig>