Explanation with an example:

  1. I'll build my-app from source.
  2. It requires some dependencies. Install them with apt-get install foo bar baz.
  3. Build the application.
  4. Install another package (hello.deb) which has a dependency to foo.
  5. Remove my-app some time later by deleting entire source folder.
  6. Remove the dependencies of my-app.

However, in step 6, you can't simply issue apt-get remove foo bar baz for the dependencies, because hello.deb still needs foo package, so only bar and baz packages should be removed.


In order to solve this problem, a dummy package may be created which declares the dependence of foo, bar, baz and we might simply install this dummy package. Later on, we can safely uninstall all those dependencies by uninstalling this dummy package. A wrapper script would build such a package on the fly and install it:

$ apt-get-named install foo bar baz
Intention: for-myapp


Would this approach work for the problem? Is there any implemented solutions for such a problem? How can we create a dummy package for such a purpose?

  • Did you take a look at apt-get autoremove?
    – PHD
    Commented Dec 27, 2020 at 1:41
  • @PHD autoremove won't work here because the packages have been manually installed. Commented Dec 27, 2020 at 2:04
  • @SuperStormer Ah you are right. I didn't read the question carefully.
    – PHD
    Commented Dec 27, 2020 at 2:15

1 Answer 1


There’s no ready-made tool to provide exactly this, because the general expectation in Debian is that someone would package my-app, and that would be the real package ensuring the dependencies remain available as long as my-app is installed (independently of hello).

There are however two tools which can come in handy in such circumstances. I suspect the most relevant one for you is equivs, which provides a quick way of creating a dummy package with dependencies; see Create a .deb package with only dependencies for details. The other tool is mk-build-deps, which is used to produce a dummy package reflecting another package’s build-dependencies, and is useful in slightly different scenarios: the goal is to keep a given package’s build-dependencies manageable as a unit. See Automatically install unmet build dependencies as detected by dpkg-checkbuilddeps for details.


You must log in to answer this question.

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