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 <[email protected]> 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) [[email protected]] -- Ubuntu-devel-discuss mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
