Re: [RFC] Proposal for new source format
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.
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. As much as possible, we
should try to centralize this information and these repositories on
project assets. That doesn't mean the maintainer needs to *only* use
project hosting or even *primarily* use project hosting, but mirroring
this information into project hosting seems like a clear improvement for
everyone.
> 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.
Agreed, altough that "as long as it is redistributable" caveat is
important. But you're right, this is a major advantage of separating the
Git repository from the source archive that I wasn't considering in my
message.
> 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.
I don't really agree with this. The advantages of encouraging people to
standardize on a VCS are huge. I'm not saying that we need to require
everyone use Git, but we should strongly encourage it, and a lot of things
in Debian will be much easier if you use Git (and should be).
That said, it may not matter that we don't agree here, since it sounds
like we're aligned on the high-level goal discussed in this thread and you
are arguing for adding an additional layer of abstraction over what I'd
add. That's fine with me; I'm happy to make compromises like that if we
can get tag2upload support for Git.
> 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.
I don't believe this is the case because, practically, I believe
interoperability with Git is going to be a mandatory feature for any
future VCS that has any hope of achieving Git's level of support and
usage, regardless of anything Debian does or doesn't do.
> 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 sounds like a fine (if more complicated) way to support tag2upload.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: