Bug#171221: openmotif: openmotif is not a native package

[Brendan O'Dea <bod@debian.org>]

On Sat, Nov 30, 2002 at 11:42:27PM +0100, Gerd Knorr wrote:
>> On Sat, Nov 30, 2002 at 05:24:58PM +0100, Gerd Knorr wrote:
>> > 
>> > "should" or "must"?  I can't find anything in the policy saying
>> > I *must* package it this way, it just says it is usually done this
>> > way.  Thus I hereby close that bug.
>> 
>> It is specified in C.3.
>
>Well, it is exactly that section -- especially the last paragraph --
>which IMHO allowes to package the whole thing as one single tarball
>instead of .orig.tar.gz + diff.  Native debian packages are listed as
>typical example for that, but I don't see noted that other packages are
>not allowed to be packaged that way.

Packaging non-native packages as .tar.gz is bad because it means that
for every little modification to the Debian packaging you have to upload
the whole lot.

Keeping the packaging seperate from the upstream source means a lighter
load on our ftp servers and mirrors.

Personally I prefer to rename the upstream tarball to .orig.tar.gz so it
is byte-for-byte identical (although this is technically violating
current policy which requires it to unpack into a .orig directory).

>I especially dislike the one-patch-for-the-whole-package approach.
>I feel more comfortable with multiple patches for multiple issues
>to fix / customize / configure / whatever.  Thats why I tar up the
>vanilla upstream tarball + the patches into the debian source tarball,
>and then do the unpacking and patching as first step of the build
>process.

A monolithic diff file does not preclude you from having separate
patches and additional files.  I keep everything under the debian
subdirectory, and have two teensy rules to patch/unpatch the upstream
source:

  # maintainer targets
  patch:
          test ! -f $(patches) # already patched
          ls debian/patches/* >$(patches)
          cat `cat $(patches)` | patch -p1

  unpatch:
          test -f $(patches) # not patched
          cat `tac $(patches)` | patch -Rp1
          rm -f $(patches)

When moving to a new upstream version, I just need to copy the debian
subdirectory and run "debian/rules patch".

The fact that the .diff.gz contains the patches twice (once applied and
once in the debian/patches dir) is a minor overhead, but one I feel is
warranted since "dpkg-source -x" will produce a directory containing the
code used to compile the package--without the need to root about
attempting to divine exactly *which* incantation is required to unpack
the upstream source/patch/whatever.

--bod