Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy
Hello,
thanks for the feedback.
Bill Allombert <allomber@math.u-bordeaux.fr> wrote:
> On Mon, Nov 01, 2004 at 10:58:55AM +0100, Frank Küster wrote:
>
>> 3. If you think a binary change is a reason for a new orig.tar.gz, do
>> you think the sentence cited above should get an exception for binary
>> files, or should it rather be dropped or rephrased completely? [Note
>> also the footnote the sentence has]
>
> I don't know, my experience is that developers that changed source
> packages to add binary files did it because they had no better idea
> on how to handle that situation. Your text address that.
Well, yes. But having no better idea might be because other options have
big disadvantages, or just because one didn't even start thinking about
alternatives. I myself have been really sloppy in repackaging in the
past, and some text in Policy or D-R could have made me think more
carefully.
>> - a README.Debian-source file added to the orig.tar.gz
>
[...]
> I disagree for practical reason: one cannot improve and fix errors in
> README.Debian-source without issuing a new orig.tar.gz which is usually
> quite painful. Allowing developers to fix that file more easily will
> lead to higher quality.
That's a good point.
> Also your proposal is not compatible with
> | A repackaged .orig.tar.gz [...] must not contain any file that does not
> | come from the upstream author(s), or whose contents has been changed by
> | you.
There is a "besides that [the README.Debian-source file]" in the "..."
part above for that.
>> Having the get-orig-source target is nice, but there might be cases
>> where this is impractical.
>
> debian/rules get-orig-source is code, not a documentation.
In this case it's both, at least if some comment says that this is the
way the orig.tar.gz was actually prepared.
> |> 3. should, except where impossible for legal reasons, preserve the
> |> entire building and portablility infrastructure provided by the
> |> upstream author. For example, it is not appropriate to omit source
> |> files that are used only when building on MS-DOS
>
> Unfortunately, there are lots of precedent for MS-DOS specific files to
> carry a non-free license, so removing them can be the safe option.
That's why I (or Henning) wrote "except where impossible for legal
reasons". Since we can include files only if the license is clear and
DFSG-free, any MS-DOS stuff which is "probably LGPL" or similar must be
dropped. But MS-DOS stuff that is surely GPL should be kept.
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Reply to: