Jonas Smedegaard <d...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871v8v21ig....@windlord.stanford.edu
