Dear Ubuntu developers, I have an experimental branch ready[0] that would allow any Ubuntu uploader to provide git commits to the git-ubuntu importer, such that it would use those commits instead of synthesizing its own. This way, the git-ubuntu will always reflect "the truth" of Launchpad publications, but also include individual git commits leading to each upload where the uploaders have provided them.
git-ubuntu already supports this through use of "upload tags", but this
doesn't scale, so this experimental branch is an effort to make it
better and available to everyone.
Question: before I land this branch, I'd like to make sure that there
aren't any issues with the "spec", as follows.
For (developer) users, you'd run something like:
dpkg-buildpackage $(git ubuntu push-for-upload) <your usual flags here>
The push-for-upload[1] command would push your branch to Launchpad and
also output some -Dfield=value arguments that would get passed through
to dpkg-genchanges.
Further/better wrappers could come later - especially for newcomers
where I'd like to wrap away the dpkg-buildpackage stuff.
Technically, the mechanism is:
1) The uploader pushes their commits somewhere.
2) The uploader includes a reference to the commits in the changes
file.
3) The uploader dputs as normal.
4) When git-ubuntu sees the upload, it pulls the commits from the
repository listed in the changes file.
5) If the commits pass sanity checks (eg. the final commit matches the
upload exactly), then it uses the commits provided instead of
synthesizing its own.
What goes into the changes file is three fields. Example:
https://launchpadlibrarian.net/516799033/hello_2.10-2ubuntu3~ppa1_source.changes
Vcs-Git: https://git.launchpad.net/~racb/ubuntu/+source/hello
Vcs-Git-Commit: 4511fdfc01cbfd5bc351e1da294d6acb44e8a4a2
Vcs-Git-Refs: refs/heads/test
We need the Refs field because git is designed not to be able to fetch a
commit by hash, but by a ref that can reach it only. So Vcs-Git-Refs
must specify what ref(s), when fetched will make the commit given to be
reachable. In practice this could just be the branch name prefixed by
'refs/heads/' as in this example.
Some thoughts:
I used Vcs-Git since this is already well-defined for debian/control
files.
For now, my branch restricts the acceptable Vcs-Git URL to Launchpad and
https, because this is the MVP for this use case and the more general
untrusted case is harder to correctly validate the input from.
Notably there's a Dgit field defined by Debian Policy against dsc files,
which is used for a very similar purpose[2].
I chose the changes file because it seemed to me that this metadata is
more to do with the action of uploading - especially since there's no
guarantee that the git repository, refs and commit will continue to be
available in the future. Long term, the correct repository and commit to
be associated with the source package would be the git-ubuntu repository
into which it gets imported, not the uploader's repository. But the Dgit
field goes in the dsc file. Maybe it makes more sense there for Dgit,
because it's better defined in Dgit-land that the commit specified will
be expected to exist indefinitely.
I've used generic field names because it made sense to me for the
changes file to be able to generally specify "this git commit is the one
that I'm actually uploading here". But I haven't conveyed what the
uploader "intends" to be done with the field. It might not be right in
the general case for git-ubuntu to always assume that the uploader wants
the commit supplied to be incorporated. So do I need another field to
specify intent, or is that over-engineering it?
The general field spec might be something to collaborate with Debian on,
and get into the spec, same as Dgit. The way I designed it, it expands
and could incorporate/replace the Dgit field. But questions on dsc vs.
changes and the intent, as I mention above, would probably need to be
resolved first. And perhaps this is more than is practical right now
anyway.
Feedback appreciated.
Robie
[0]
https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/396756
[1] Not yet implemented. I'm not sure of the best name for this
subcommand; suggestions appreciated.
[2] https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-dgit
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
