On Sat, Aug 24, 2013 at 2:33 PM, Jonas Smedegaard <d...@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 _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
