Create a binary Debian package

[Colin Watson]

On Mon, Jan 25, 2021 at 11:38:47AM -0800, Alex Chen wrote:
> Thanks for the information Colin.  However, this is a binary package built from proprietary cross-platform source code.  
> It is not open-source nor free software.  There is no up-stream source package.

That doesn't matter for the purposes of my reply.

> > On Jan 25, 2021, at 6:51 AM, Colin Watson <cjwatson at ubuntu.com> wrote:
> > On Sun, Jan 24, 2021 at 11:21:01PM -0800, Alex Chen wrote:
> >>   I am trying to create a Debian package, i.e. a .deb file, that can install  software in Ubuntu. I put a the following files under the build directory:
> >> 
> >> build_dir/DEBIAN/control - Package configuration
> >> build_dir/DEBIAN/md5sums - MD5 checksums of every files to be installed.
> >> build_dir/DEBIAN/preinst postinst  prerm postrm - Pre/Post installation and pre/post uninstallation scripts.
> > 
> > You should never create files under DEBIAN/ directly.  Build a proper
> > source package instead with the appropriate files under debian/, and
> > build binary packages from it using debuild.  See for instance
> > https://wiki.debian.org/Packaging/Intro.
> 
> It is not built from with 'configure' and 'make' from the source. The standard Linux build configuration does not apply.
> It is packaged with a script following the descriptions in https://www.debian.org/doc/debian-policy/ch-binary.html#binary-packages <https://www.debian.org/doc/debian-policy/ch-binary.html#binary-packages>

Source packages don't require the "standard Linux build configuration"
(there isn't really such a thing anyway, but rather a variety of common
build systems).  They don't require configure or make, or indeed any
other build step.  It's perfectly possible and commonplace to have a
source package that simply copies a bunch of prebuilt files into place,
or that runs pretty much whatever script you like.

None of this is a reason to construct the .deb by hand by poking into
DEBIAN/, and you'll just make trouble for yourself by doing so - you can
and should still use the normal packaging toolchain.

Also, another thing I just noticed: for dependencies on shared
libraries, you should normally use ${shlibs:Depends} in debian/control
rather than writing those exact dependencies out by hand.  This makes it
easier to update the package to build correctly on newer versions of the
OS.  You can't do this if you're building DEBIAN/control by hand - it's
a facility provided by the packaging toolchain.

> >> This what I have in the 'control' file
> >> =====
> >> Package: test-package
> >> Version: 1.0.0
> >> Architecture: amd64
> >> Pre-Depends: coreutils, libicu60, libfontconfig1, firewalld, unzip, zip, curl, lapache2, apache2-bin
> >> ======
> >> 
> >> I thought packages listed in Pre-Depends field of a control file are supposed to be installed by the system before it process the package itself, according to this document: https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends <https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends>
> > 
> > Pre-Depends should only be used in rare circumstances.  You should
> > normally use Depends instead.  You also don't need to (and shouldn't)
> > explicitly depend on coreutils, since it's an essential package.
> 
> In order for our software to function, several packages not usually present in a base system need to be installed first and according to the definition of 'Depends' and 'Pre-Depends', 'Pre-Depends' seems to be what is needed.
> 
> Depends -  Requires other packages it depends on to be 'unpackaged' or 'configured',
> 'Pre-Depends' - Requires 'dpkg' to complete 'installation' of these packages before event installing the package itself.

In general, the only reason you need Pre-Depends is if you're using the
dependency in question in your package's preinst script, and even that
is often a mistake that can be avoided.  (There are occasional other
cases that really only come up if you're maintaining something that's a
core part of the OS itself.  I'm familiar with what the Debian policy
manual says, and am summarising the essential points here since it's
often misunderstood.)

The Debian policy manual says "You should not specify a Pre-Depends
entry for a package before this has been discussed on the debian-devel
mailing list and a consensus about doing that has been reached", not
because of some kind of gatekeeping, but because Pre-Depends imposes
stronger constraints on the packaging system that can cause upgrade
difficulties down the line, and most of the time Depends turns out to be
sufficient.

We can probably advise if you can give us more details, but it's
unlikely that just putting all your package's dependencies in
Pre-Depends is going to turn out to be correct.  For the usual case
where additional dependencies are required for a software package to
function, Depends is the field to use.

-- 
Colin Watson (he/him)                              [cjwatson at ubuntu.com]