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 i...@metux.net -- +49-151-27565287