[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

> 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

> >> 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: