Working with debianized sources not in ubuntu

[Emmet Hikory]

Tim Bielawa wrote:
>  I'm not sure how to deal with source that's already been debianized.
>  There is a small blurb here on the wiki but I am not certain how to
>  interpret what it says. The package I'll be updating and packaging for
>  Ubuntu/Debian has an incorrect directory layout (<package>-<version>
>  instead of <package>_<version>) and their FSF address is outdated, along
>  with an "ancient" outdated Standards: version.

There are a few things you can do, with roughly decreasing benefit.

The most common recommendation is to ask the upstream author to
removing the packaging information from the release tarball.  There
are lots of distributions out there, and while it's best to share
code, upstream is typically focused more on core functionality than
packaging, so tends not to prioritise changes to the packaging.
Further, different distributions, and different releases of the same
distribution may have different binary package names for dependencies,
depending on library transitions, chosen package splits, etc., which
tends to increase the chances that packaging information from upstream
is incorrect (not by any fault of upstream, but simply because it may
not be possible to construct packaging information in such a way that
it is suitable for all distributions).  Upstream may want to maintain
a debian/ directory in their VCS for their own conveniece in testing,
but should be encouraged not to put this in the release tarball.

Where upstream cannot or will not do this, the next best option is to
start from the upstream packaging, and modify to suit the target
distribution and release (e.g. Intrepid Ibex).  Unfortunately, diff.gz
cannot represent the removal of files, so in some cases the packager
may have to use the --ignore flag with debhelper, in which case there
should be a versioned build-dependency on debhelper (>= 5.0.57).  A
complete refresh of debian/changelog is commonly requested, and a
careful investigation of copyright, control, and rules to be sure that
they match current practices.  In these casees, it is almost never a
good idea to change the overall packaging model (e.g. change to/from
CDBS) as this tends to increase the confusion when migrating to a new
upstream version.

Where upstream cannot or will not remove the directory, and the
upstream packaging directory cannot be overlaid with acceptable
packaging, the least desireable option is to remove or rename the
upstream debian/directory in a repack of the upstream tarball.  This
should only be done as a last resort, where no other option is
available.  If this option is selected, every effort should be made to
coordinate with packagers or maintainers for other distributions to
maintain a common tarball, facilitating patch exchange, etc.

In all cases, where there are other issues with the upstream release
tarball separate from packaging (directory layout, inclusion of
temporary generated files, outdated compilation hint files, inclusion
of unlicensed code or data, outdated license information (most
commonly an incorrect address for the FSF), code with an incompatible
license, code with bugs, etc.) these should be reported upstream.
Many can be patched away in the diff.gz, but most will be interesting
to all distributions, and every benefits from cleanup.

-- 
Emmet HIKORY