Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy
On Mon, Nov 01, 2004 at 10:58:55AM +0100, Frank Küster wrote:
> [I'm not subscribed to -policy, please respect M-F-t or Cc me]
>
> | 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.
> `----
>
> This poses the following questions:
>
> 2. Do you think that - although alternative methods exist - a binary
> file may be changed or added by creating a new orig.tar.gz file? Or
> do you think this must be done by adding a uuencode'd file (or
> similar) in diff.gz?
I think it is more of a practical matter. If you have a few binary files
to add, uuencode them. ( Also remember that Debian menu icons must be in
XPM so you don't need to uuencode them.) When a new upstream version
appear, you can reuse the diff.gz and automatically get the binary files
without messing with the tarball.
If you have a whole directory of binary files, you might consider
making a new source package for them. (For example a Debian theme
for a program).
> 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.
> 4. What is the right place to document the changes made to the
> orig.tar.gz file? Some possible places would be
>
> - the get-orig-source target in debian/rules (see Policy 4.8)
>
> - a README.Debian-source in the debian directory (i.e. in the
> diff.gz)
>
> - a README.Debian-source file added to the orig.tar.gz
> Personally, I think that the last possibility should be a
> requirement. The main reason is that I think that our archive should be
> a good source for Free Software even when one does not want to use the
> Debian Operating System (and indeed we provide lots of mirrors for
> software with no or only a couple of mirrors). It would be annoying if
> one had to download the diff.gz just in order to learn what was changed
> in the orig.tar.gz file.
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. 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.
> 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.
If you provide a script that build a new orig.tar.gz without user
hand-holding, then you should arrange for debian/rules get-orig-source
to call it, especially if the script is likely to work with new
upstream version.
> One final question: I'd like to have a footnote at the beginning of the
> new 6.1.3, explaining a simple case where it is necessary to add or
> change a binary file. I can imagine several, but I'd like to have one
> that can be explained in one or two short sentences without lengthy
> discussions about DFSG-freeness or non-automated generation of pdf files
> or whatever. Suggestions?
Adding some PNG files to use in the Debian configuration ?
|> 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.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: