Re: How to include information about a source package ?
Bart Martens <bartm@knars.be> writes:
> A description of why and how the source was repackaged, should go in
> "README.Debian-source or a similar file".
This is a statement from the Developer's Reference that I think I disagree
with. I do already know it's there, so repeating it doesn't make it more
likely that I'm going to agree with it. :)
> Copyright and distribution license(s) information should go in
> debian/copyright. I don't think that other information belongs in
> debian/copyright.
> http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-origtargz
> http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile
I think Policy implies something different:
In addition, the copyright file must say where the upstream sources
(if any) were obtained.
Explaining how the .orig.tar.gz file was derived is part of explaining
where the upstream sources were obtained to me. I can see how others
would read it differently, but that's the way it read to me the first time
I read Policy.
Policy says nothing about a README.Debian-source so far as I know.
>> run the target, and compare the results of the target with the
>> .orig.tar.gz that they were using. That would replace the normal
>> sponsoring check of downloading the upstream tarball and checking with
>> cmp that it is identical to the .orig.tar.gz.
> The sponsor should compare the upstream .tar.gz and the .orig.tar.gz
> with md5sum. If the MD5 checksum differs, then the sponsor should
> unpack both files and compare with "diff -ruN" or something like that.
> Each difference should be documented in "README.Debian-source or a
> similar file". The get-orig-source may be convenient to do less typing
> and to quickly understand how the .orig.tar.gz was created, but
> basically, the sponsor should still verify in detail whether each
> difference is appropriate.
I think that the approach that I outlined accomplishes the same thing, is
less manual, and is more thorough. I see no reason to prefer the approach
you outlined to the one that I outlined. Usually (there are some
exceptions) I find it much easier to thoroughly review the code that makes
transformations than the result of applying those transformations.
One advantage of insisting on a get-orig-source target as part of the
review is that it ensures that the derivation of the .orig.tar.gz file is
automated and reproducible, making it easier and quicker to package the
*next* upstream release of the software.
>> In all cases, I don't see much purpose in having a separate
>> README.Debian-source document.
> Well, it was a choice made in the past. In my opinion it was a good
> choice. But feel free to discuss this again, and have the Debian
> Reference changed about this.
Well, discussing it is exactly what I'm doing right now. :) Obviously if
I can't convince anyone here, there's no point in filing a bug against the
Developer's Reference for a change that has no consensus.
>> Maybe if the repackaging were so complex so as to not be representable
>> in a debian/rules get-orig-source target.
> Repackaging upstream sources should be exceptional. Also, verifying a
> repackaged .orig.tar.gz needs full attention anyway, so doing the
> repackaging manually to verify is good anyway.
I find automated processes more reliable than manual processes. If it's
an exceptional case that requires careful review, it's even *more*
important to automate where possible so that humans don't miss things by
accident and can review the information-dense representation (the
automation) as opposed to the information-diffuse representation (the
results of the automation).
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: