Bart Martens <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
