Re: DEP5: non-DFSG repackaging documentation
Jonas Smedegaard <dr@jones.dk> writes:
> I am fine with Source field permitting free-form text, as long as the
> scope of that field is limited to covering the question "where did
> upstream release the source that was the main basis for this package?"
I think where we're disagreeing is that I don't see any real difference
between that and what we're discussing. To me, "this package is based on
the tarball released at URL with the following four files removed because
they're under a non-DFSG license" is stating the upstream origin of the
software. I think you're dividing that description into two separate
pieces in a way that I find artificial and which draws a distinction that
I don't mentally make.
I can make that distinction if that's what the standard says that I should
do, but it doesn't seem worthwhile to me.
> Let me put it another way: I cannot easily (e.g. using md5 or SHAnnn
> checksum) verify data redistributed if repackaged, even if containing
> same files: the binary chunk called a tarball is no longer pristine.
> Your more extreme example of not using tarball at all, but generating
> from Git has same issue: the binary result of running that "git archive"
> command will never be the same. It is irrelevant that the command is
> simple to invoke.
Well, yes, but I'm not sure I see why that specific verification tool
should be particularly privileged, except because it's nice and simple
(which I agree is a nice feature, but not horribly relevant from a Policy
perspective). You can still verify what source I'm using by retrieving
that Git tag and diffing it against the upstream source used by Debian.
It's just a bit more resource-intensive to do the verification.
> The reason this bothers me is that we then cannot extract a list of
> source packages (voluntarily using DEP-5) for which the redistributed
> source is not upstream pristine source.
devref already offers a way to do that separate from DEP-5, so I'm not
sure this is all that important for DEP-5. (6.7.8.2 point 4)
> I believe that the Policy requirement of documenting stripped data is to
> document when we "distort" upstream source in our redistribution of it.
Just to be sure everyone's on the same page, there is no explicit Policy
requirement to document stripped data. There is only a Policy requirement
to document the origin of the upstream source. I believe that naturally
includes documenting any stripping that was done, but Policy doesn't
mention that explicitly.
>> In the case that I'm thinking of, upstream also distributes tarballs; I
>> just choose not to use them for a variety of reasons.
> Now you get me curious ;-)
Upstream generates release tarballs with ancient versions of Autoconf and
Automake and with man pages generated by an ancient version of pod2man,
all of which I would then have to delete and regenerate in the Debian
package building. This is annoying to deal with and maintain in a Git
repository, since it affects hundreds of files. Since I'm regenerating
all those files anyway, I just package based on the Git tag, which doesn't
include any of those generated files and makes the package build process
much cleaner and simpler.
It also makes it simpler to merge the Debian source with the upstream
source in Git so that I can use Git cherry-pick and similar tools to
manipulate the source in a straightforward way. There are ways to do this
including the tarball release as well, and I used to use them, but this is
a lot simpler and having the upstream tarball isn't horribly useful.
Finally, the upstream tarballs include the source for the Windows
implementation as well, which is 52MB (since it includes lots of
translated Windows-specific documentation) that is completely
uninteresting to Debian. Given that I'm generating a custom tarball
anyway, I filter out that part of the tree so that we don't have to
replicate it in our archive to no purpose.
>> In the end, I suppose this is all bikeshed painting and I'll use the
>> field name no matter what it's called, though.
> I feel it is not, but if you judge this as nitpicking, I shall stop.
Sorry, that probably came across poorly. I was referring to my own
contribution as bikeshed painting, not to yours. I'm probably making too
much of this. :)
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: