I'm creating a Debian package that has a few dependencies not found in the official repositories. Simply specifying these other packages as dependencies doesn't cut it, as their installations alone involve running apt-get update and adding source repositories (which aren't mine) to /etc/apt/sources.list.d.

More: one of these packages is Dart language SDK - which you can only install by grabbing their deb and using dpkg, or by adding one of Google's repos. My goal is really just finding a balance between minimizing the number of steps involved in my package's installation and clean package deployment.

So I'd like for my package's pre-installation script to add these sources and then run apt-get update, but the main problem is that when the package is open and being installed it puts a lock on dpkg. So is it possible to achieve what I'm after directly, or what other options/workarounds are there?

  • I'm not sure what you mean by "their installation involves running apt-get update and adding source repositories (to /etc/apt/sources.list.d)." Source repositories for what, exactly? Can you be more specific/detailed about your setup? Regardless trying to do an end run around the packaging system in this fashion is not likely to end well. Commented Apr 22, 2015 at 17:14

1 Answer 1


I don't think its possible directly.

But somehow the user got your package to install—and apparently not from your repository, since it hasn't been added yet. So the first workaround I'd suggest would be to do things the normal way: have the user add the repository (or give the user a simple shell script), then install your package as normal. This would be my preferred solution, and running a shell script is no harder than installing a package.

Second workaround: have your package just be a setup package. Have it set up your repository, then tell the user (e.g., via debconf note or other prompt on screen) to install the real package (which will come from your repository).

Third workaround: Same setup package, but use the same package name in your repository, just a higher version (use an epoch, probably). So the initial install will set up the repository, then apt upgrade or similar will pull in the real package.

Fourth: I'm not sure this is a good idea, but—In your postinst, fire off a background process that will wait for the dpkg lock, then finish your install. I think at or batch will work for this, or just an ordinary /path/to/script & followed by disown. You probably want to let the user know that the package install will finish in the background.

PS: you probably need to add a GPG key as well.

  • Could you elaborate a bit more on the second workaround? I'm not sure how that solves the issue if it's still a package that can't run pre/post-install scripts to manage other apt-get installation functions.
    – Crunchy
    Commented Apr 23, 2015 at 15:07
  • @Crunchex I've clarified the 2nd workaround—I meant "tell the user" literally. Also, I came up with a fourth one, which should work without further user interaction.
    – derobert
    Commented Apr 23, 2015 at 16:12

You must log in to answer this question.

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