Re: Survey results: git packaging practices / repository format
>>>>> "Daniel" == Daniel Reurich <daniel@centurion.net.nz> writes:
Daniel> As a lurker and pervasive packager of the downstream Devuan,
Daniel> I thought I'd share some of my thoughts on this as git has
Daniel> been the core of our work flow and build system.
Thanks for joining the discussion!/
Daniel> For background ref, Devuan uses git for all packaging.
Daniel> We've never supported building from anything other then git
Daniel> sources. All our packages are built straight out of our git
Daniel> repository using Jenkins ci with Jenkins-Debian-glue (jdg)
Daniel> The jdg splits the package building into 3 separate phases -
Daniel> source build (uses gbp), binary build, and uploading to our
Daniel> repository (dak)
Daniel> Our packaging approach is more or less "unapplied" for
Daniel> 3.0(quilt) packages, and (I think) pretty much universally
Daniel> using quilt and gbp - only for changelog and buildpackage
Daniel> (because it does a nice pbuilder based build process with
Daniel> all the checks for ensuring no stray patches to the upstream
Daniel> source sneak in).
Daniel> We've universally stamped out using pristine tar ;-) and
Daniel> always use use either upstream-branch or preferably
Daniel> upstream-tag. This works pretty well and we can usually
Daniel> merge from salsa (and formerly alioth) tidy up the changelog
Daniel> conflicts.
How do you handle merging from salsa if the packaging you are merging
from is not in unapplied format.
For example let's say I add a hard systemd dependency to krb5 (I have no
such plans) and you want to patch it out.
Krb5 is git-dpm, which is a patches-applied tree.
What would you do if you wanted to merge my packaging?
Reply to: