Re: [RFC] Proposal for new source format
Hi Russ
On Mon, Oct 21, 2019 at 09:29:05PM -0700, Russ Allbery wrote:
> If we're going to go to the trouble of defining a new source format, I'd
> prefer we embrace a VCS-based one rather than once again rolling our own
> idiosyncratic representation of a tree of files
I'm not completely sure what you mean with "VCS-based". You want to add
a complete repository (dump) to the source? Do we need to define a
subformat for each VCS then? CVS, SVN, GIT, just to name some used
ones. In any case we would be defining our own representation anyway,
because each VCS behaves different.
Also this would negate all the things we've accomplished on
reproducibilty of source packages.
> their history.
We never shipped history as part of our source. Was this asked for?
dpkg currently supports "3.0 (git)" as format, however it was never
accepted by the archive. There is a reason for that, as this would
force license reviews not only on the current state, but on the history
as well. We would also just distribute arbitrary information we don't
actually need to ship to hundred of unrelated mirror people and would
bring them into jeopardy.
If something really problematic slips in, we also would be forced to
remove all intermediate versions, because they ship the history.
> Even
> if one is not convinced of the merits of uploading a true Git history of
> the package, I think it's clear that a lot of us *do* want to do this and
I think we are talking about different things. I'm talking about the
source we _must_ provide to fulfil several licenses and our own policy.
If we save them in the form of snapshots.d.o for example, we have a
complete history of the releases.
You are talking about the detailed history, a history that might not
even be accurate, as it can be changed retrospectively.
Just think about what would happen if a contributor adds code he must
not distribute for whatever reason. Another contributor finds this and
removes it before any release happens. This shows up some time later
and we get angry mails or letters stating we ship stuff we must not. So
we now need to purge this information everywhere, even if it was never
inside a release.
You still would need to prune it from the one (few?) central VCS, if you
use such thing. But the project don't need to handle the hundres of
public copies out there, owned by hundreds of operators providing us
with mirror space
> see this as a very valuable step forward in providing a more complete
> history of the package and of decisions made in maintaining that package.
Even then you need additional information like the BTS to know the
decisions.
I think I understand what you mean and we have different goals.
I want to modify how we ship the source we _must_ ship, where we don't
have the option not to. Just make the handling of it less painfull,
without sacrifice too many things we currently have.
You want to ship more info in immutable form. Info that have the
abbility to bite us, the whole project, and many other people, just by
distributing it.
I hope this makes the reasons clear, why I proposed what I did and not
further.
Regards,
Bastian
--
Punishment becomes ineffective after a certain point. Men become insensitive.
-- Eneg, "Patterns of Force", stardate 2534.7
Reply to: