On 17276 March 1977, Russ Allbery wrote:
So, in short: A t2u uploaded source package should consist of
whatever
t2u produces (normal Debian source package) *plus* two additional
files.
The first file contains client side generated data, but to *not*
overburden the client, this *only* consists of the output of `git
ls-files --format="%(objectmode) %(objectname) %(path)"` for the tag
that should be uploaded, signed by the DD/DM key - or something
similarly easily generated on client side. Exact format can be hashed
out between t2u people and ftpmaster during implementation.
You describe the contents here, but not the semantics, and I'm not
sure
that I fully understand what the intended semantics are (in other
words,
what packages dak will accept under this proposal). Would source
packages
that contain additional files not represented in this list of files
and
hashes be accepted, for example?
dak sets no limit on the packages here. That is, no matter what t2u has
to do in its blackbox, go and have fun. Just include the signed list of
files from the maintainer plus the shallow clone.
The intention is that enough gets uploaded and stored somewhere that dak
(or whoever later) can reconstruct what t2u did. And, obviously, if you
then follow the steps t2u does and use as input the shallow clone
(verified against the maintainers sig), it really should get identical
output. (Maybe minus timestamps, but for the important part).
Here's one specific concrete example for one workflow using tag2upload
(there are other variations): suppose I, as the uploader, tag a Git
tree
that is patches-applied with no patches in debian/patches/*. I run
the
above command and include that signed data somewhere where tag2upload
can
get at it via the Git tag. tag2upload then turns that into a 3.0
(quilt)
package and uploads that package along with the information as
requested,
including that list of files and hashes that I signed from the tree
that I
tagged.
In the thing I described it does not matter what t2u does, and yes, what
it uploads may well contain more or less files, or changed files, from
what the maintainer signed and started the process with. But those are
all added/removed/changed files from the t2u process, so ought to be
able to be redone, taking the same starting point. If *that* isn't true,
something would be fundamentally wrong.
When dak sees the package, all of the files in debian/* in the source
package will have the same hashes as in the git ls-files output, but
the
source package will have additional files in debian/patches/* that do
not
exist in the git ls-files output. Some of the upstream files will
have
hashes in the git ls-files output that match the contents of those
files
after unpacking the source package (and thus applying patches), but
will
not match the hashes of those files as they exist in the upstream
orig.tar.gz.
In this proposal, would dak be willing to accept such a package?
Unless dak goes and redoes the work that t2u is doing, ie. construct the
whole thing from git and whatever magic needed, dak will not care, if
the files in the source package are modified by t2u.
The case of a repository that contains only the debian/* files poses
another set of complications, but I don't think we have to get into
that
immediately. The above examples are probably enough to work through
to
understand what the intended semantics of this manifest is.
I'm not entirely sure on what is best to require here. I mean, the orig
source has to be somewhere, including on the maints machine, so should
be possible to be included in this without any extra large magic.
The second file consists of a shallow git clone of the repository for
the tag that t2u wants to upload, put into an appropriately named
tarball.
Just to double check, to make sure I'm not missing some subtlety, it's
intentional that this file contains all of the same information as in
the
first file, and the first file is just a subset of this same
information
in a different form?
It's not the same. The first contains a list of things with hashes or
something (whatever will be defined between t2u and ftpmaster). The
second contains the actual data. But yes, you can generate the first out
of the second - except for the maintainers signature.
In other words, someone could verify the signature on the Git tag in
this
file and then run the git ls-files command on the Git repository and
get
exactly the same information as in the first file, so the first file
is
technically redundant. I can think of some reasons why you might want
that, but it's a little surprising, so I wanted to make sure that's
intentional.
And yes, you can get the exact same thing out. Thats how you can verify
it later, if it matches. I mean, we CAN condense it down to "the
maintainer does the shallow clone and signs that, and that gets
uploaded", but I think that goes against the "simple on the client
side".
--
bye, Joerg
