Mapping dput uploads to git commits and the Dgit control file field

[Robie Basak]

Hi,

I'd like to talk about the Dgit control file field and a related need I
have. I wonder if there's any possibility for collaboration on a single
spec that serves similar needs.

I've posted to this list before about work Nish and I had been doing to
do with git integration in Ubuntu development. Much has happened since
then. The project got renamed to "git-ubuntu" and I stabilised and
released git-ubuntu 1.0 in September[1].

I'm now looking to add a feature to allow Ubuntu uploaders to provide
our importer with git commits, instead of having them synthesized. My
experimental branch uses a few additional fields in the changes file.
The requirement is very similar to dgit's use of the Dgit field in dsc
files. So I'm wondering if there's an opportunity here to define
something more general that everyone across Debian and derivatives could
use.

I posted[2] a provisional outline spec to the Ubuntu developer list last
week.

Key differences to the Dgit field:

1) My new fields are in the changes file, not the dsc file.

2) Three fields are required. One is the commit hash, same as Dgit. The
other two specific where the repository is and what refs make the commit
reachable. Dgit requires these too, but they are fixed by specification
in the Debian policy manual so do not need to be specified in the dsc
file.

The idea is that when a developer uploads a package, they may be doing
it from a git commit, and so the changes file simply specifies where
that git commit may be found. I'm thinking of this as a general concept
that is not specific Dgit or git-ubuntu.

The reason I'm putting this in the changes file and not the dsc file is
that in my case (and therefore the general case), there is no guarantee
that the referenced commit will continue to exist in the given
repository. So it's not really "part" of the source package in my view
(though I think it is in Dgit's case).

The three fields I'm adding are:

Vcs-Git: [same spec as from debian/control]

Vcs-Git-Commit: [unabbreviated commit hash]

Vcs-Git-Refs: [the first whitespace-separated field is the globbable ref to
fetch as the first part of a refspec; further fields undefined]

You'll notice that this is virtually identical in purpose to the Dgit
control file field. Except that dgit's Vcs-Git and Vcs-Git-Refs fields
are constants.

Example changes file:

https://launchpadlibrarian.net/516799033/hello_2.10-2ubuntu3~ppa1_source.changes

Is this something worth collaborating on a spec on? I would prefer to
avoid changing behaviour later, since git-ubuntu can reproducibly import
packages from the beginning of time, and to maintain that would mean a
flag day for a spec change as well as maintaining multiple behaviours
forever.

Robie

[1] https://lists.ubuntu.com/archives/ubuntu-devel/2020-September/041188.html
[2] https://lists.ubuntu.com/archives/ubuntu-devel/2021-February/041346.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/vcs-pkg-discuss/attachments/20210204/d91ff0a4/attachment.sig>