Re: t2u in the archive
On 17277 March 1977, Ian Jackson wrote:
Firstly, you say a "shallow clone".
It is not straightforward to include *precisely* the set of commits
that are required to reproduce the output. The conversion might, in
principle, go arbitrarily far into the maintainer's packaging branch;
and, if the conversion involves an external tool such as
git-debcherry, that tool probably won't currently report what
commit(s) it used - so would need to be modified.
I'm hoping the reason you say "shallow clone" is simply to avoid
bloat.
Yes.
In that case, it's fairly simple: I find it difficult to imagine a
future workflow that includes the history *of the upstream branch*.
So the t2u server could exclude commits which are in the history of
the nominated upstream tag. That would generally do the right thing,
but it wouldn't *guarantee* not to include unwanted history. Would
that be OK ?
Yes.
Secondly, the file listing. Thanks for the explanation. I'm still
not quite sure we understand why you want it.
Even so, I think I have a possible way to eliminate it, while still
giving you the property that dak (or a future audit) can know the file
list of the tree signed by the maintainer, without needing to actually
run git.
(I'm guessing that having dak not run git is why you don't think it's
good enough that one can verify the contents directly from the git tag
by running the git-ls-files rune.)
The git tag is itself a Merkle tree, containing the information you
need. So the hashes of all these things, and the filenames, are
already signed by the maintainer - that's the git tag. The reason
it's not readily verifiable without running git itself, is mostly
because getting the actual object texts out of git is very
complicated.
How about we (the tag2upload team):
[... long description ...]
Honestly I think that sounds way more complicated than a "git ls-files
something" based file and process, and binds us more tightly to actual
git than ls-files does (one could easily have more fields in there, if
deemed neccessary).
But I don't see anything obviously so wrong that its a NO, so fine.
The new listing program could be written in the language of your
choice. (I'm volunteering to write it.)
While I personally love Rust nowadays, dak is python, so python that
will be. (While it won't be integrated into dak (so easier for others to
take), it should share the same language).
--
bye, Joerg
Reply to: