Web lists-archives.com

Re: Survey: git packaging practices / repository format




On 28.05.19 22:30, Ian Jackson wrote:
> Hi, thanks for replying.  You have an interesting workflow which I
> think I need to ask some questions about before I can document it
> fully.

I'd call it the 'git-only-workflow' ;-)

The main reasons behind are:
* i wanna be able to easily rebase onto upstream anytime
* i wanna keep generic changes separate from the distro-specific stuff
  (usually I try to do very generic, so it can go into mainline, eg.
  instead of directly patching things like pathes, etc, I'm adding
  new build options, ...)
* i wanna easily bring generic changes upstream
* i don't ever like to cope w/ text-based patches anymore (all these
  apply/unapply cycles really suck :p) - git is much easier to handle,
  IMHO
* i wanna have exactly the build tree in my git repo
* i don't wanna versioning patches (reading diffs of diffs are not quite
  useful :o)

Actually, the workflow is a tiny bit more complex: i'm using layered
branches (regularily rebasing):

layer 0: upstream releases
layer 1: per release maintenance branches w/ generic (hopefully
         upstreamable) fixes - based on the corresponding upstream
         release tags (or potentially their maint branches)
layer 2: per distro and release debianized branches
         (sometimes some layer 1.5 for really generic deb stuff)

Branches and tags have a canonical naming - ref name prefixes,
canonical version numbers, ... (eg. anyting for debian stretch is
prefixed 'stretch/' ...)

Years ago, I've already tried to form layer 1 into a greater,
cross-distro community, where stabelization efforts are shared between
many distros (kinda send-patches.org but w/ high grade of normalization
and automation. It was called the 'oss-qm' project (github org with same
name). But the interest from dist maintainers was asymptotically
approaching zero, from below.

> Enrico Weigelt, metux IT consult writes ("Re: Survey: git packaging practices / repository format"):
>> I'm always cloning the upstream repo, branch off at their release tag
>> and add all necessary chanages as individual git commits - first come
>> the generic (non-deb specific) patches, then the deb specific ones.
>> No text-based patches, or even magic rewriting within the build process.
>> The HEAD is exactly the debianized source tree,
> 
> What source format do you use ?  What is in debian/source/format, if
> anything ? 

Usually "3.0 (quilt)", but I actually don't really care so much. Just
picked that some time, as it just worked, and never really though about
it anymore :p

> Do you handle orig tarballs at all ?

No. I'm exclusively using docker-buildpackage, which directly operates
on the final source tree - no intermediate steps like unpacking,
patching, etc.

One of the fine things (besides simplicity) is that if anything goes
wrong, I can just jump into the container (it intentionally doesn't
clean up failing containers) and directly work from there (the git
repo is also there).

> When you go to a new upstream, you make a new git branch, then ?

git checkout <prev-maint-branch> -b <new-maint-branch>
git rebase <new-upstream-tag>

And then see it it works, finxing things, etc.
Of course, I'll also care about self-consistent and understandable
commits - git history is documentation, not rotating backup ;-)

> Do you publish this git branch anywhere ?

https://github.com/oss-qm

(from time to time I also send patches upstream)

>> which is then fed to dck-buildpackage.
> 
> What is that ?  

https://github.com/metux/docker-buildpackage

It's a little tool that sets up build containers (also creates base
images on-demand), including build tools, extra repos, etc, runs
the build in the container and finally pulls out the debs.

The main audience are folks that maintain extra repos (eg.
customizations, backports, etc) - that's one of the things I'm
regularily doing for my clients.

I've got another toolkit ontop of that, which helps maintaining
whole repos, including managing git repos and their remotes,
dependency handling, etc. It's actually not a standalone tool,
but a fundation for easily setting up your own customized build
environment. I'm using it for all my customers who get apt repos,
but also for backports and depotterization.

(Note: the 'master' branch currently is crappy, more a playgound, w/
lot's of things that have to be cleaned up ... for production use
fork from 'base' branch.)

> manpages.debian.org wasn't any help.

It's not in official Debian. I've announced it long go, but nobody
here really cared. I couldn't even convice debian maintainers for
little less insane scm workflows (just look at the kernel :p), but
failed, so I don't waste my time anymore, instead just clean up the
mess for those packages that I actually need.


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@xxxxxxxxx -- +49-151-27565287