Discussion on eventual transition away from source packages
Joerg Jaspert writes ("Re: Questions about "Winding down my Debian involvement""):
> On 15348 March 1977, Sean Whitton wrote:
> > I won't write a long reply because it's not that important to the DPL
> > election, but I did want to note that `dgit push-source` has answers for
> > everything you've listed. I'd encourage you to take a(nother) look!
>
> Do those answers only apply if you still think of the traditional source
> archives to upload, or also if one envisions to go away from that?
If we were to abolish the part about uploading traditional source
packages, what remains of `dgit push-source' is simply pushing a
signed git tag with a conventional name to a designated server, and of
course pushing the corresponding commits to a designated git branch.
(There is a dgit-infrastructure package which knows how to verify
these tags and do the access control for the designated per-suite git
branch in the right way: specifically, in an identical way to the
existing Debian archive.)
In this scenario most of dgit would no longer be needed, because
dgit's primary function is to gateway bidirectionally between source
packages and git branches.
`dgit push-source' (which has frantic paddling ill-concealed beneath
its fairly friendly exterior) would be replaced by a tiny shell script
in devscripts to do a few checks and then help you make the right tag
name and push it to the right place. [1]
That place would not be the main salsa master branch of course,
because for the reasons you give, because we don't intend to abolish
*binary* packages. So there needs to be an explicit developer action
to declare a particular set of source code as the one to build binary
packages from, for testing and distribution to Debian's users. That
explicit developer action would consist principally of making a
suitable PGP signature, as now - except the signature would be on a
git tag, rather than a .dsc and .changes.
`dgit push-source' is halfway towards this, because it's part of my
transition plan. It makes *both* the signed git tag, and the
.dsc/.changes signatures.
Incidentally, if you are a Debian derivative you can already stop
using source packages. `dgit clone' and `dgit fetch' from Debian from
will give you git branches which you can build directly. Then you can
just git push the result to any git server, wire it into your CI, and
so on. The only thing you lose is that you can then only distribute
your source code via git, rather than as .dscs, but the latter are an
obsolescent compatibility format.
There is room for improvement in the tools for managing a Debian
derivative's automatically-rebasing delta queue from Debian. Peter
Green of Raspbian has written a autoforwardporter which does some of
this work...
Ian.
[1] I use signed tags because handling signed pushes on the server end
is a lot of work. Signed commits are unsuitable because they have the
wrong security model, indeed for basically any problem - see my blog
posting here:
git signed commits are a bad idea
https://diziet.dreamwidth.org/515.html
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Reply to: