Re: How to include information about a source package ?
On Sun, Apr 30, 2006 at 12:05:19AM -0700, Russ Allbery wrote:
> Bart Martens <bartm@knars.be> 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.
Reply to: