Quoting Felipe Sateler (2013-08-26 00:09:49) > 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.
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
signature.asc
Description: signature
_______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
