I'm trying to create a DEB package from my own sources.
Everything is fine except handling the dependencies.

As I understand, the most genuine way to mark the dependencies is to list them in the Depends section of the control file. My application requires two packages (aapt and zipalign) which are present only in the recent Debian (≥ jessie) and Ubuntu (≥ willy) repositories, so there would definitely be a problem installing my .deb on the older ones.


Several thoughts on this question:

  • Install the needed standalone binaries (as a part of my .deb) to /usr/bin.
    • PRO: The needed dependencies are present in my package as stand-alone binaries, so the Depends section won't be used, and the missing repository packages won't be a problem.
    • CON: If the destination binaries already exist on the target machine as a part of another package, dpkg will encounter an error, and forcing the user to pass --force-overwrite option is not a greatest idea.
  • Install the needed standalone binaries (as a part of my .deb) to /usr/share/myapp.
    • PRO: The application uses its own isolated directory for the third-party binaries, so it does not alter the potentially existing packages (and, again, the Depends section is no longer needed).
    • CON: The share directory is intended for an architecture-independent data, which the binaries are not.
  • Install the whole application to the /opt/myapp directory.
    • PRO: This method does not violate the FHS structure and keeps the files in a totally isolated directory.
    • CON: However, this is not an authentic UNIX way, especially for the opensource software.
  • Use the Recommends section instead of Depends for a weaker relation and provide some instructions to users on how to get the lacking packages.
    • CON: The .deb package itself loses the point.

None of these methods seems right to me. Are there any standard ways to handle this problem, did I miss some obvious solution? For example, some kind of conditional installation would be very helpful (install the third-party binaries only if the which command outputs nothing, etc.).

Any thoughts and advises would be appreciated.

  • There's solution 1b: provide builds under a name like myapp-zipalign and let your tool either fall back on that name or have configurable tool names. Aug 7, 2016 at 10:54
  • @UlrichSchwarz That is an interesting solution. Could you please add your comment as an answer so I can upvote it?
    – kefir500
    Aug 7, 2016 at 11:12

1 Answer 1


Provide (in addition to your main package) separate packages aapt and zipalign. Make sure they have ~ in their version (like this: zipalign-21-4~kefir1.deb). Then put them in your repository togheter with your main package which has Depends: aapt, zipalign (I use easy reprepro for hosting my repository, it's not hard).

This is the Debian way (the same way backports.debian.org works) - if system is Jessie and provides aapt, that will be used (as you package has tilde in version, it is only used as last resort). If the system is older Debian, only then your extra packages will be pulled. And the users get the benefit of easy-to-get upgrades/security fixes to your packages.

Additinal advantage is that on upgrade on Jessie, official packages will be pulled and overwrite your older extra pacakges (unless you specifically depend on specific version or extra packages, of course). And so you do not have old/duplicate versions hanging around, and users get additional benefits of debian security team patches etc.

  • Thank you for the answer, +1. However, if I understand correctly, this method involves creating a personal repository which needs a server to be hosted on (and the local one makes the deb package useless for other users).
    – kefir500
    Aug 7, 2016 at 18:46
  • @kefir500 yes. You need to distribute your .deb package somehow, and that is usually done by putting it up on some website for download. Repository is nothing more than files in few directories on some website. While you could possibly send users .deb files via email, or putting them on dropbox or something, that is not common. And even if you do that, having separate .deb files as explained would still benefit you and your users better than other alternatives (for example, upgrading to Jessie would automatically upgrade those obsolete binaries even if you do not have repository) Aug 8, 2016 at 0:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .