Re: [RFC] Proposal for new source format
Russell Stuart <russell-debian@stuart.id.au> writes:
> That is a great definition of reproducibility if all you are interested
> in is the Debian version of the package. It is not so great if you want
> is the upstream version of the package - ie, it is important to you that
> it behaves identically or at least diverges in accountable ways. In
> that case you want a clear audit trail from the upstream source to the
> Debian binary.
If you modify the upstream source, then by definition you do not have
reproducibility of the upstream source, and you're now talking about
something else (review of the changes, which I called audit in my previous
message). Surely this is obvious? My definition does extend
reproducibility all the way back to upstream in the case that upstream is
unmodified.
In retrospect, for the modification case, I missed explicitly stating that
there should be some verifiable way to identify the point of divergance
from upstream and verify that this point matches the signed upstream
artifact, but for what it's worth that was part of my mental model.
I agree that audit is also interesting, but I object to confusing it with
reproducibility.
> What is important to me is the source contain an audit trail or how
> Debian got from the upstream source to the Debian package. If I
> understand your position correctly, your proposal boils down adding a
> (single) branch to the upstream .git for the debian changes.
I have no idea how you got that from my previous messages, but you have
misunderstood. I haven't talked at all about what representation in Git
should be used, since I think one of the features of standardizing on Git
is that you have all the substantial tools of Git available to you to find
a meaningful representation for your package. That includes rebasing
workflows if they make sense, feature branches, and so forth.
> My problem isn't with using git - it's with the word "single". It isn't
> even with you using a single branch, as perhaps that's appropriate for
> the packages you maintain (which it would be if the only change is to
> add a debian directory). My problem is the implication that since it
> good enough for you, it's good enough for every package. It's not.
> When you are carrying a lot of changes it's bloody horrible.
This is exactly my objection to reducing everything to patches rather than
using the power of Git to represent the history and structure of the
changes made for Debian.
> I can see how you might think that. The reality is a different. At no
> stage have I suggested you should be prevented from using git, or indeed
> any other mechanism you desire. I have said if you adopt a new system
> like dgit please figure our a way of implementing one feature the one
> you are replacing (quilt) - a way to audit changes.
I agree with the importance of retaining the ability to audit changes, and
am completely baffled by your belief that this is inherently easier to do
with quilt than with Git. I think maybe you're confusing the tool with
the implementation and are actually arguing in favor of a rebase workflow
for managing changes to upstream source, in which case we agree and this
is exactly why I use rebase workflows with my packages. Using Git.
> But it has been proposed that everybody be forced to drop whatever
> workflow they might like in favour of dgit, and you look to be arguing
> in favour of that idea.
This sentence makes no sense to me. dgit is not a workflow.
I'm fairly certain that I'm not in favor of whatever you think I'm in
favor of. I don't recognize my position in your summaries.
> With the current split between development format and source
> distribution format you get to develop in any way you please. If it
> wasn't split now there would have been no dgit. The source format can
> be optimised for distribution and in fact is so optimised. It is pretty
> much as efficient as it can be - it contains all the things you need to
> work on the source, and little else.
Yes, it's becoming clear that I'm retreading an argument that the dgit
developers already went through and have arrived at agreement with their
conclusions: we should have a lightweight, history-free, minimal source
package representation (which I believe is also the problem that Bastian
is trying to solve in the message that started this thread), and we should
separately have a proper representation of the package history for the
people who find that data valuable and important.
dgit largely achieves the second part (I think it doesn't for all possible
Git representations, but that's a solvable problem without long
debian-devel threads and can be driven by someone using a different
workflow who wants to use dgit); the remaining piece that I want is a
tag-based push workflow so that we can provide a native upload process for
developers who are used to a Git-centric way of working, rather than the
(from their perspective) arcane and complex mucking about with unfamiliar,
Debian-specific artifacts like source packages. Those who care about
source packages can continue to use them if they want; those who don't can
ignore them as an implementation detail of tag2upload.
Given that, belated apologies to Bastian for taking this thread in an
unproductive direction. If a new 4.0 source format unblocks the issues
raised with tag2upload (although it would be great to spell out exactly
how that would happen), I'm all in favor.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: