Re: Survey: git packaging practices / repository format
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
info@metux.net -- +49-151-27565287
Reply to: