Re: [RFC] Proposal for new source format
I think this discussion has conflated two separate needs that should be
kept distinct. The current source package provides a record of how the
binary packages were built from source. This includes signatures and
verifiability of source, and, more recently, reproducibility. It
provides the ability to build the binary packages on a user's own
machine, and can be a starting point for building them in an environment
not supported by Debian (in simple cases this might be exactly the same
as building on a current Debian architecture).
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 do believe that Debian should strongly encourage use of a publicly
accessible VCS for packaging, and should define some VCS-agnostic
standards that the repositories SHOULD (RFC implications) follow, e.g.
basic branch structures, tag naming conventions, etc.
Separating the source package from the VCS repository, but having both,
allows both Russ' and Russell's goals to be met easily.
One important aspect of this separation is that the VCS can include the
original, unmodified upstream source, as long as it is redistributable
in that fashion. It has always bothered me that the modifications
needed to convert the upstream source to a DFSG-compatible source are
lost in the Debian source package. Keeping the VCS separate allows it
to contain the original, non-DFSG source and show what was done to make
it DFSG and why. It will also help to facilitate using a single
repository to build both a source package for main and a corresponding
source package for non-free, when that is appropriate.
[Perhaps the following should be moved to the Git Packaging thread, but
I think much of this sub-thread could also be said to belong there.]
I think the VCS-agnostic aspect of this has not been brought up in the
related "Git Packaging" thread, but I think this is important. While
git is overwhelmingly the most popular VCS, it is not the only one (it's
also not my preferred VCS for usability reasons). I think it is
short-sighted for Debian policy to mandate or even to strongly encourage
a specific VCS. This effectively shuts down the use of any other VCS,
and extremely hinders attempts to get a new or better VCS to be used for
Debian development.
Debian should separate everyday development with the VCS from
interaction between the VCS and the Debian archive. The tools provided
for the former can be very VCS-specific, and can make full use of that
VCS' features.
The tools for interacting with the archive, e.g. making it trivial to
upload a signed commit to be built on official Debian hardware, should
define a very small set of standard features necessary to accomplish
that, such as clone, commit, checkout, push, pull, and tag (with
signature). This API should have a minimum of options, and it should be
easy for someone to implement a shim from that API to a specific VCS.
This separation would allow much greater freedom of choice, but still
allow the developer to take full advantage of the chosen VCS.
...Marvin
Reply to: