Re: Bug#466550: Pristine source from upstream VCS repository
Bernd Zeimetz <firstname.lastname@example.org> writes:
> No, please don't just add another watch file just for the sake of it,
> using these files is more or less like living in the last
> century. People are able to get the current source from the Debian pool,
> if that is not enough for them, they should be old enough to be able to
> click on the upstream homepage link in the package's description and get
> the source.
> A lot of people, including myself, prefer to pull form the upstream vcs
> directly, and work on top of that, using git for example. Using uscan to
> retrieve the exact version is often impossible, as it's not trivial to
> get a tarball from a specific upstream branch, tag or ref.
> I think the way Debian should go is to tell people that they should
> clone the developer's git ([.. insert your favourite dvcs here ...])
> repository and work with it, probably requiring to explain how working
> with the repository works, which branches are used for what, and so
> on. At least that would fit *todays* way of handling packages, at least
> for a lot of people.
Hm, I think I disagree with most of this.
First, I think this new habit (which you don't mention directly but
somewhat allude to) of not making stable formal releases is a very bad one
and I would strongly encourage any of my upstreams to not go down that
path. The difference may be more psychological than technical, but it's
important to assign a version number on something and push it out the door
and declare it released. Otherwise, projects have a strong tendency to
drift into perpetual development mode, where it's a crap-shoot whether any
given feature will be working at the moment and often it's quite difficult
to find a point in time when everything is stabilized. I have one
upstream that does this "just use the VCS" thing and in practice it's
incredibly obnoxious for trying to get their software into Debian.
If there are stable upstream releases, I think that's what the Debian
packaging should be based on. If you also want to use Git remotes to
track the upstream revision control repository so that you have more
fine-grained metadata, that's great, but I think a lot of clarity and
reproducibility is gained by having upstream release a tarball and by
basing the Debian package on exactly that tarball. There's a lot to be
said for a clear export and externalization from the VCS that everyone can
synchronize with, regardless of tools.
On the topic of finding the current upstream release, I definitely don't
agree with the idea that the home page link solves this problem. Some
upstreams have extremely bizarre release processes, poor home pages, no
real home page at all, or make it difficult to figure out just where the
source is at. Having a watch file that embeds all of the packager's
existing knowledge about how to find the upstream release is very
Also, I think you're underestimating the utility of being able to find
exactly the tarball that was used for generating a given Debian package.
It allows independent verification of the package in the archive (useful
in some security scenarios), and it's very important for package
sponsorship where one should not trust the orig.tar.gz provided by the
sponsoree unless you already know the sponsoree well.
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>