Re: DEP5: non-DFSG repackaging documentation
Jonas Smedegaard <firstname.lastname@example.org> writes:
> On Tue, Sep 14, 2010 at 06:23:12PM -0700, Russ Allbery wrote:
>> It seems like overkill to me, but I guess I don't really care. But if
>> the source is only URLs, then for some of my packages I either need to
>> omit it or duplicate Homepage, since I don't use any tarball release
>> from upstream and therefore have no URL to point to. I package a Git
>> tag instead, for which there's no URL syntax.
>> Or I guess just include the URL of the upstream instructions on how to
>> use Git.
> In my opinion you should as accurately as possible point to the location
> of the upstream source, i.e. refer to the upstream Git URL if that is
> the one you base your packaging work on, and only to the toplevel
> Homepage of the upstream code project if no other more narrow URL for
> sources (e.g. if each new source release is in a different
> subfolder). Source URLs need not be http URLs, I believe.
For weird cases where there isn't a simple location for the sources (such
as with a dead upstream with no active web site), I think a textual
explanation is way more useful than any sort of URL. If Source requires
URLs, I would just omit Source entirely in that case. It's already
optional, so that seems like a supported approach.
>> But that field name also isn't an accurate representation of what's
>> going on when the packaging is based on a Git tag. No manipulation is
>> involved other than running git archive against a tag.
> Point is _you_ ran that command, not upstream. So _you_ created the
> tarball that Debian redistributes, not upstream.
> True, you did not edit any of the content of any individual files inside
> the tarball, but you did edit the _tarball_ content: You created all the
> timestamps in there, for example.
I think you're stretching here. :)
I don't like Source-Manipulation at all as a field name. I'd much prefer
we use something else. My personal preference is for just making Source
free-form, since I don't see any utility in having it be machine-parsable.
Failing that, something neutral like Source-Details or Source-Description
would work better for me.
> I find it relevant that we document when what we redistribute is not
> what upstream distributes.
Sure, I agree with that.
> In your case upstream distributes Git data which we do not (yet) support
In the case that I'm thinking of, upstream also distributes tarballs; I
just choose not to use them for a variety of reasons.
> So it makes sense to me that you document that for our users.
> Optionally - it is not mandatory to document that.
It's mandatory to document the origin of the upstream software.
I'm not disagreeing with you about the documentation requirements. I just
don't like Source-Manipulation as a field name and don't see much point in
requiring the Source field be URLs.
In the end, I suppose this is all bikeshed painting and I'll use the field
name no matter what it's called, though.
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>