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.
You can also tell apt-get autoremove
to ignore “Recommends” and “Suggests”:
sudo apt-get autoremove -o Apt::AutoRemove::RecommendsImportant=false -o Apt::AutoRemove::SuggestsImportant=false
Use -s
to get a list of the removals this would lead to without actually changing anything:
sudo apt-get autoremove -s -o Apt::AutoRemove::RecommendsImportant=false -o Apt::AutoRemove::SuggestsImportant=false
Best Answer
The control file is static so no you can't change dependencies on some external parameters but the Debian Policy specifies
|
as a way to specify alternative package names, in your case it would be something like:where
Package1
is the default dependency.