Re: Documenting packaging workflows
Johannes Schauer Marin Rodrigues <josch@debian.org> writes:
> I would be *very* interested in more in-depth write-ups of the workflows
> other DDs prefer to use, how they use them and what they think makes
> them better than the alternatives.
> Personally, I start packaging something without git, once I'm satisfied
> I use "gbp import-dsc" to create a packaging git with pristine-tar (and
> that will *not* have DEP14 branches and it will use "master" instead of
> "main") and then I push that to salsa and do more fixes until the
> pipeline succeeds and lintian is happy. My patches are managed using
> quilt in d/patches and upstream git is not part of my packaging git. I
> upload using "dgit --quilt=gbp push-source".
> Would another workflow make me more happy? Probably! But how would I get
> to know them or get convinced that they are better? Maybe I'm missing
> out on existing write-ups or video recordings which explain how others
> do their packaging and why it is superior?
One of the lesser-known things found in the dgit package is a set of man
pages describing several packaging workflows. These certainly aren't
exhaustive of the packaging workflows that people use (for one thing, they
are designed to explain how to use dgit in each workflow, and thus of
course assume that you want to do that), but they're both succinct and
fairly thorough and I found reading them very helpful. dgit(1) has a list
at the start.
dgit-maint-debrebase(7) is the workflow that I now use, pretty much
exactly as described. The primary thing that I like about it is that I
never have to deal with the externalized patches or with quilt (I used
quilt for years, and I have developed a real dislike for it and its odd
quirks -- I would rather only deal with Git's odd quirks), and I can use a
git-rebase-like command in much the same way that I use it routinely for
feature branches when doing upstream development. Then some Git magic
happens behind the scenes to make this safe, and while I don't understand
the details, it has always worked fine, so I don't really care how it
works. :)
I like having a Git history from as early in the process as possible and I
want the upstream Git history to refer to while I work on packaging (and
want to be able to cherry-pick upstream commits), so I generally start
with a tagged release from the upstream Git repository, create a branch
based on it, and start writing and committing debian/* files.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: