On Sun, Apr 30, 2006 at 12:05:19AM -0700, Russ Allbery wrote: > Bart Martens <[EMAIL PROTECTED]> writes: > > 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.
I agree that this interpretation is very reasonable. With this interpretation, the debian-policy and the developers-reference seem to contradict on where to describe how the .orig.tar.gz was repackaged. > One advantage of insisting on a get-orig-source target Do you insist on a get-orig-source target while sponsoring? It's currently optional according to the debian-policy. http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules > 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. The next upstream .tar.gz may be completely different. Trying the get-orig-source target on a new .tar.gz without first having a look inside that new .tar.gz before, can make a mess. Also, repackaging a .orig.tar.gz should be avoided. It is better to encourage the upstream author to make the repackaging unnecessary before the next upstream .tar.gz is released. That is, of course, not always possible. > >> 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. :) I love a good discussion. :) > 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. Filing such a bug and starting a discussion on other mailing lists (debian-devel?) could make more people participate in the discussion. Maybe the consensus becomes what you want, I don't know that now. But I guess that some parts of what we're discussing now may already have been discussed in the past years, so doing some googling before may be wise. > >> 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 A sponsor should not trust a get-orig-source target written by the sponsoree (is that correct english?). The sponsor should redo the repackaging of the .orig.tar.gz step by step to verify whether each step is appropriate. > and can review the information-dense representation (the > automation) as opposed to the information-diffuse representation (the > results of the automation). Wow, I had to read that a few times. :) So, with all aspects discussed so far, I still think that README.Debian-source was a good choice, and that it's OK that the get-orig-source target is optional. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
