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. <[EMAIL PROTECTED]> Imagine a large red swirl here.
