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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
