Re: Improvements to ‘debian/watch’ for fetching from VCS
On Tue, Apr 07, 2009 at 11:53:07PM -0500, Manoj Srivastava wrote:
> > The Debian archive is *not* the canonical location for the upstream's
> > original source. The upstream's repository (whether VCS or static
> > files or whatever they make available) is the canonical location.
> > Debian's archive might be more consistent and convenient, but it's an
> > intermediary source for most packages, *not* canonical.
>
> As far as Debian is concerned, it is: this is the orig.tar.gz
> that the diff.gz needs to be applied to in order to get the
> Debian package in the archive.
As far as Debian's distribution is concerned, this may be the case.
As far as Debian's developers are concerned, being able to fetch the original
source before being prepared for DFSG conditions is vital to being able to
collaboratively develop and sponsor packages.
>
> Whatever is upstream may or may not produce the package we have
> (it could have been corrupted, updated, or whatever).
>
> >
> >> I am not seeing the sue case for not getting the sources
> >> distributed by Debian from Debian. People who do not trust
> >> the Debian archive, ought not to trust the Debian script,
> >> and go get the upstream using a trusted download agent on
> >> their own; so security is not the use case.
> >
> > Trust isn't binary. One use case is to confirm what re-packing of an
> > original source archive has been done. Another is to verify whether
> > perhaps *upstream* has fiddled with the original source archive since
> > Debian packaged it. Yet another is to get an original source archive
> > that hasn't yet made it into Debian's archive.
>
> Most of htese checks, while laudable, ought not to bload either
> uscan, or debian/rules, since these are far off topic, in my opinion.
Off topic? What does that even mean in this context?
If these checks are going to be done, they are going to be done from a file
within the debian directory, why should it matter too much which file that is.
Indeed, I would rather reuse an existing, and known, quantity.
>
> >> By far the most common use case I can see is to get the
> >> latest upstream, and do whatver munging needs to be done to
> >> make it acceptable for Debian as a source archive.
> >>
> >> What am I missing?
> >
> > It's not at all unusual for me to *not* want to get the latest version
> > precisely because I'm not ready to package that version, or because it
> > is worse (FSVO worse) than the version specified in
> > ‘debian/changelog’.
>
> I think that is usually an uncommon case. And we ought to be
> coding to the common case, while not making the uncommon cases impossible.
Both of these cases are common for me.
My typical workflow when developing a package is to fetch the upstream source
many times as I develop and patch against it. I use a number of computers, and
work over a number of days. In each of these cases, this requires the source to
be pinned to the exact number in debian/changelog. When I am finished, I pass to
my sponsor, who will also want the exact version.
Only when I am initially starting a new version of the package will I request
the newest upstream, and as soon as I have done that, I will pin its version
number in debian/changelog anyway.
I think that arguing that either one of these cases is uncommon enough to be
marginalized for the other seems absurd on the face of it. I'm not even sure
what you're proposing be the outcome of "coding to the common case" is.
Best,
--
Noah Slater, http://tumbolia.org/nslater
Reply to: