Simon Richter writes ("Re: Why Debian is dying (Was: Call for volunteers and GR
draft: tag2upload key installation)"):
> Git is not a packaging tool. There is no way to have a "native"
> git-based packaging workflow.
Certainly there is. We've built it.
Theare are at least two really good ones for a maintainer, described
in detail in dgit-maint-merge(7) and dgit-maint-debrebase(7).
There is also a git-first NMU workflow which works for *any* package
so long as you aren't trying to do a new upstream version.
That's described in dgit-nmu-simple(7).
There are some missing pieces, so you still end up with tarballs
floating about. That's not great even though you can mostly ignore
them. tag2upload is part of the answer, and unblocks more.
(tag2upload is trying to make dgit obsolete.)
> 2. use 'apt build-dep x' to install the build dependencies locally
> 3. build the package with 'dpkg-buildpackage -b -us -uc' to see that it
> works
> 4. use 'dch -i' to create a new changelog entry
> 5. make local changes
No-one who has become comfortable with git will want to work this
way. How will you even know what local changes you've made, without
git diff to tell you?
Instead, folks do `git init && git add .`
But there are better options nowadays.
> Even "how you create a changelog entry" is not uniform, much less
> "how to register a patch" or "how to rebase patches for a new
> upstream version."
With all of the workflows I mention above there is no such thing for
you to do as "registering a patch". You simply make git commits, as
normal. You can touch upstream files and debian/ files. You should
write good commit messages - as normal.
The tooling will automatically do the right things. The dgit NMU
workflow works and regardless of the source package format. It works
regardless of whether the maintainer uses dgit, although you see a
better view in the git history if they do.
It's true that making changelog entries is a thing you need to do and
that the way to do it isn't "standardised" but that doesn't matter
very much because it's not that hard and the output is standardised.
New upstream versions are indeed nontrivial. As I say, doing this
well for a patch series is an open research problem. Every downstream
(not just distros) has the same problem.
But even for this, git-first answers are the best answers.
If your delta from upstream is empty small or absent, git merge works
great. This will be the case for most packages. dgit-maint-merge(7).
If you actually want to maintain a patch stack, git-debrebase can do
the rebase tracking etc. for you. With git-debrebase the same git
branch can be used by Debian novices who can just make commits, and by
the experienced packages who are introducing new upstreams.
> The git-based workflows are a great collaboration tool, but to use
> them you already need to understand the Debian packaging tools and
> git, then on top there is also the policy on how branches inside the
> repository are used.
On the contrary, git-first workflows radically reduce the amount of
Debian-specific knowledge you need. Especially, they radically reduce
the amount you need to learn before you can even get started.
I blogged about this here, addressing downstream users:
https://diziet.dreamwidth.org/17579.html
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
