[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DEP5: non-DFSG repackaging documentation



Jonas Smedegaard <dr@jones.dk> 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
> redistributing.

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 (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: