"apt-get --ignore-missing install" fails when it can't find a package

Bug #512190 reported by Travis H.
40
This bug affects 6 people
Affects Status Importance Assigned to Milestone
apt (Ubuntu)
Opinion
Undecided
Unassigned

Bug Description

Binary package hint: apt

I have a script for configuring Ubuntu after installation. I'd like to be able to run one apt-get command to download and install all the packages I normally use. Unfortunately, the availability of a package varies over time and release. Upon reviewing the manpages, it appears that "--ignore-missing" should do what I want, but it still causes apt-get to fail:

sudo apt-get --ignore-missing install kdvi; echo $?
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package kdvi
100

Now, I could loop and run "apt-get install" for every package, ignoring the exit codes, but that doesn't seem to be the way apt-get is supposed to be used.

If --ignore-missing does something other than what I want, the manual pages need to make clear exactly what it does. Furthermore it seems reasonable to request an option to allow apt-get to proceed even if it doesn't find all the requested packages - failing to install ANY of the specified packages when one isn't present seems to be the wrong behavior in this context.

ProblemType: Bug
Architecture: amd64
Date: Sun Jan 24 21:31:21 2010
DistroRelease: Ubuntu 9.10
Package: apt 0.7.23.1ubuntu2
ProcEnviron:
 LANGUAGE=
 PATH=(custom, user)
 LANG=C
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-17.54-generic
SourcePackage: apt
Uname: Linux 2.6.31-17-generic x86_64

Revision history for this message
Travis H. (travis+w-launchpad-net) wrote :
Revision history for this message
Torsten Spindler (tspindler) wrote :

I believe aptitude would be a better fit for your usage.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in apt (Ubuntu):
status: New → Confirmed
Revision history for this message
Christian Hudon (chrish) wrote :

Actually, aptitude is not a great fit for that kind of usage, as it will also happily start automatically uninstalling a bunch of packages that are "not needed" anymore (not available upstream). And there's no way to prevent it from doing that. It also searches in the package description, etc. instead of just the package name, which is much slower when one have a long list of packages to install or remove.

Revision history for this message
Daniel Hartwig (wigs) wrote :

It is clear from the man page that ‘--ignore-missing’ is intended only for packages that exist but fail to download correctly or can not be downloaded at the time. Requesting a package that does not exist is well outside the scope of this option and is an unsafe operation to simply ignore.

The former is typically due to transient network errors that clear up in a short time. The later is a seriously broken request.

Changed in apt (Ubuntu):
status: Confirmed → Opinion
Revision history for this message
kernc_ (kernc) wrote :

Then perhaps a new option --ignore-invalid should be provided?

There are use cases for this, particularly when the list of package is dynamically constructed. For example, when localizing packages, a most general script could be:

locale="pt-br"
package="iceweasel-l10n-"
lang="pt"
apt-get install --ignore-invalid $package$locale $package$lang

for any reasonable choice of variables. The only working alternative, currently, is:

for p in $package$locale $package$lang; do apt-get install $p; done

which is far less efficient.

Revision history for this message
kernc_ (kernc) wrote :

another use case is this:

apt-get install $package_list

Above line does not survive any transition of a Debian release where one package in a list becomes inexistent for one reason or another. This sucks. Who is maintaining this?

Revision history for this message
David Kalnischkies (donkult) wrote :

So, you are saying that it is okay to run scripts which are no longer maintained? And that we should help script writers to write scripts which are not maintained but should not fail in the future (at least not in an obvious way)? Those are the same "helpers" run with --yes (and sometimes --force-yes), right?

Completely ignoring my personal opinion on those "helpers": Renames aren't covered either. What used to be a game, is now a browser (chromium) and what used to be tools for file and process operations is now a version control system (git). A handy-dandy helper setting up a tlh environment in distro v1 stops doing the same in distro v2 because packages got renamed, dropped, whatever… are you going to tell a badly tempered Klingon he should be happy, that the script at least didn't complain loudly, even if it didn't worked in the end?

Its not that hard to check for existence of a package from a script if you really want to. And even if you don't, apt-get is accepting more than just simple packagenames on the commandline (did I hear someone saying regex?) so if you really want to, you can have all the cake and eat it now already. No need for yet another obscure option, way too much already.

Revision history for this message
kernc_ (kernc) wrote :

Localizing LibreOffice, one may want to install:
  libreoffice-l10n-{lang or sometimes locale}
  aspell-{mostly lang, sometimes locale}
  hunspell-{...}
  mythes-{...}
  ...
Would you advise everyone in all cases that they incorporate additional checks for each possibility? Where's simplicity?

It is against sensible non-purist programming paradigm to not provide a way to gracefully default.

--------------------

The solution for my use cases above is:

echo "package-x install\package-y purge" | dpkg --set-selections && apt-get dselect-upgrade

dpkg at least has a (in this case default) way to gracefully continue.

Revision history for this message
David Kalnischkies (donkult) wrote :

apt-get install '^(libreoffice-l10n|aspell|hunspell|mythes)-(pt|pt-BR)$'

And as you was already told, erroring out if a package you explicitly requested for install is a graceful default – and the only sensible choice as what is the alternative: Implicitly ignoring explicit requests?

Revision history for this message
kernc_ (kernc) wrote :

> Implicitly ignoring explicit requests?
No, in case of apt, I'm strongly convinced the --ignore-invalid option should be explicitly provided to achieve this behavior. :-)

Anyway, using regexes seems to work well. Thanks.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.