On 29.05.19 14:47, Sam Hartman wrote: Hi,
> I'm certainly going to look at dck-buildpackage now, because what he > describes is a workflow I'd like to be using within Debian. :) Maybe you'd also find that useful: https://github.com/metux/deb-pkg It's a little tool for automatically creating whole repos, eg. automatically cloning repos (even w/ multiple remotes), building whole dependency trees (deps are explicitly configured instead of fetched from the packages, intentionally), etc. Note: the "master" branch is pretty hackish, basically an example - the idea is to branch off from "base" for each project and do the necessary changes directly in git. (from time to time it's worth rebasing). > For some projects I want to ignore orig tarballs as much as I can. I'm > happy with native packages, or 3.0 quilt with single-debian-patch. single-patch isn't so nice for interacting w/ upstreams. > I don't want merge artifacts from Debian packaging on my branches. > I'm happy to need to give the system an upstream tag. I'd prefer always having a debian branch ontop of the upstream release tag and doing all the debianziation there, possibly per-release or dist release, flavour, etc. > I'm happy for a dsc to fall out the bottom, and so long as it > corresponds to my git tree I don't care how that happens. ACK. I see dsc just as an autogenerated itermediate stage for certain build systems (eg. builldd) or providing src repos. > I have a slight preference for 3.0 format over 1.0 format packages. 3.0 > makes it possible to deal with binaries, better compression and a couple > of things like that. The quilt bits are (in this workflow) an annoyance > to be conquered, not a value. ACK. That's why I do everything in git only. I don't really care how the src packages look like, as long as I've got an easy and fully automatic way for getting a clean git tree with all the necessary changes already applied as readable (and documented) git commits. > The thing his approach really seems to have going for it is that he > gives up on the debian history fast forwarding and instead rebases a lot > for a cleaner history. ACK. Personally, I don't see any actual value in an separate Debian history, or even an history of the text-based patches. git-rebase is one of my primary daily tools. > If we could figure out a way to collaborate on something like that well, > it might be a very interesting tool to have. ACK. I believe we should set some computable policies on how orig trees are generated from actual upstream repos and patches are handled, so we can do imports/transformations fully automatically. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287