Re: [RFC] Proposal for new source format
On Wed, Oct 23, 2019 at 11:40:06AM -0700, Russ Allbery wrote:
> Marvin Renich <mrvn@renich.org> writes:
>
> > The source package has historically (prior to the widespread use of VCS)
> > also provided the basis for future development. Since most development
> > these days is done using VCS, it's natural to try to adapt the source
> > package to contain the VCS. I believe this is a mistake. I think the
> > source package should remain a succinct encapsulation of the source
> > required to build a specific version of the binary packages. It should
> > also identify the canonical VCS location where new development occurs
> > (and from which this snapshot was taken), but it does not need, and
> > should not have, the complete VCS history.
>
> I think I'm coming around to this position. I don't think it's the best
> or most elegant design in the abstract, but given where we're starting
> from and the various concerns involved, it does seem like the most
> practical design.
I think we will need to support the source tar.gz for the forseeable
future. At very least, *deprecating* the tar.gz/tar.gz.asc format
should be independent of question we also support a format that
involves a URL to a git repoistory plus a signed git commit ID or a
signed git tag.
> That said, I don't like accepting the idea that we're always going to
> point to random different VCSs per package, which may be down,
> inaccessible, deleted by the maintainer, and so forth. I don't want to
> force anyone to do anything, but I think there is immense value in the Git
> repositories created by dgit from archive uploads, and that value gets
> even stronger if those repositories are enhanced by including the
> maintainer and upstream history where available.
I believe that the hypothetical git source format which involves a git
URL must involve a git server under the Debian project's control.
That is, Debian must keep a permanent archive of the git repository,
regardless of whether or not it is the primary repository for the
purposes of making changes. Certainly the dgit repositories would
qualify, but potentially other git hosting solutions might qualify.
I do think, though that we should allow the specification of
*multiple* git repositories, with some kind of type specifier so it
can be clear whether a particular repository is just a read-only clone
versus a read/write "master" repository, and whether a
repository+branch is the upstream repository, and/or used by the
debian maintainer's to maintain its packaging.
It probably would also be useful if the metadata had some standardized
way to indicate the preferred way to propose changes to either
upstream or the debian packaging maintainer --- whether it's e-mail to
a particular e-mail address, or a pull request, etc.
- Ted
Reply to: