Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy
Chris Waters <firstname.lastname@example.org> wrote:
> On Mon, Nov 01, 2004 at 01:47:02PM -0600, Manoj Srivastava wrote:
>> How about this rule of thumb: If you get stuff from the
>> primary NON DEBIAN distribution site, that is what you call
>> upstream. What someone unconnected to debian, not using debian
>> archives, downloads is what we also offer as upstream orig.tar.gz
> I think it's more important that our users *know what they're getting*
> than that we try to enforce some sort of arbitrary distinction between
> "Debian" and "upstream".
I think Manoj made an important point in a reply to me when he stressed
that a "source package" in Debian is a *.dsc file and the files
mentioned therein, with their checksum. If you think that way, everybody
who looks at a Debian source package still "knows what they're getting"
if the putting-together is explained in a file in diff.gz, doesn't he?
> Clarity is why I chose "107.0pre108" as a
> version number. I don't see how it's that much different from our
> various cvs-snapshot packages, except that in my case, upstream wasn't
> using any sort of version control at the time I made the package -
> they just had a loose collection of patches and replacement files
> available on their website.
In this case it seemed to me that upstream was not willing to prepare a
release, to put together the pieces at that time. At least there was no
consensus to do this. But you - both upstream developer and Debian
developer - decided that it was time for putting together what was
currently available, and create a Debian package.
This was probably a good deal of work, and of thinking and deciding in
the first place. I would argue that this was work for Debian - upstream
as a team did not do it, and no other distribution will probably have
used the same state of the project for packaging. And if it is work for
Debian, it is appropriate to document it in files in diff.gz, isn't it?
>> Pristine upstream means pristine upstream. Either get your
>> notes added to upstream website, or put them in the diffs.
> We don't require "pristine upstream". For example, we remove non-DFSG
> compliant portions. Many licenses require that changes be
> documented. So if we modify the upstream source to remove the
> non-DFSG portions, and _don't document that_ (because of a new policy
> rule that forbids any debian-authored portions of _orig tarballs),
> then we may be violating licenses.
There may be a grey area, because even if *we* consider a source package
to be "$package.dsc, sed -e '/^[^ ]/ d;/^ / s/.* //' $package.dsc",
somebody else might still just look at the orig.tar.gz.
On the other hand, this is a grey area also in a different sense: It
restricts modification of the source, and the type of restriction is not
grandfathered (at least not literally) by clause 4 of the DFSG. And if
you take the combination of both: Upstream source that contains non-DFSG
material and forbids to use the DFSG-free parts without explicitly
referring to the removed non-DFSG-free parts, well, IANAL, and
IANARODL, but I wouldn't like this.
 "Debian comes in three flavors: Stale, rusting, and broken, which
are renamed once or twice a decade. Actually, rusting is stale yet
currently, but it can't be officially released before 2004, because
Gnome2 and KDE3 aren't sufficiently outdated, and a messed-up inn for
broken is missing"
 I Am Not A Regular Of Debian-Legal
Inst. f. Biochemie der Univ. Zürich