maemo.org Bugzilla – Bug 601
should offer remove/install multiple packages at once
Last modified: 2012-03-24 11:42:40 UTC
You need to
before you can comment on or make changes to this bug.
Since the installer now supports repo's and nicely resolves dependencies by
itself, this also means it may install a whole heap of packages when the user
selects one single application.
Unfortunately, to get rid of all those packages afterwards, the user has to
select each of those packages individually and have it removed. There should be
means of selecting multiple packages for deinstallation.
Ideally, when uninstalling a Software, the Application Installer should check
the dependencies. It should offer to the user to deinstall an additional list of
packages which were probably brought along with the no longer desired
installation and which are not used by any other software in the system any
more. That way, deinstallation would be as intuitive as installation and a lot
of unnecessary clutter from test installs could be avoided.
For a start, the Application Installer could at least have some indicator
bgcolor) for all packages which can be uninstalled without getting a dependency
error. Because sometimes it is really hard if not frustrating to get rid of a
dependency tree of some uninstalled software otherwise.
Created an attachment (id=77) [details]
Sorry attached the package to wrong bug...
(In reply to comment #0)
> Unfortunately, to get rid of all those packages afterwards, the user has to
> select each of those packages individually and have it removed. There should
> be means of selecting multiple packages for deinstallation.
Yes, probably. Also, it would be nice to offer to automaticall uninstall the
packages that need to current one instead of giving the error message. E.g.,
Instead of "Unable to uninstall. Package foo is needed by blah, baz." the AI
could say "Package foo is needed by blah, baz. Uninstall them as well?"
However, you might consider using "non-user" packages. The AI wil only list
"user" packages in the UI (packages with a "user/FOO" section field), but will
happily install non-user packages to satisfy dependencies. When a user package
is removed, these non-user packages will be removed with it (if possible).
That way, you can make a "user" meta-package and put the meat of your appliction
into non-user packages.
Quim added to cc-field
*** Bug 3837 has been marked as a duplicate of this bug. ***
Marius, this is one of the oldest enhancement requests still open.
Your Comment #4 is quite old as well. Anyupdate about your opinion on this
request and the possibility to integrate it in Fremantle or Harmattan?
fwiw this feature is missing in the current Fremantle build. Applications ned
to be removd/installed ine by one as usual.
This might get blamed as a very naive comment, but isn't this basically adding
a list variable of all marked applications and iterating the
installation/removal (and the dependency checks) for each app in that list?
Code is at
(In reply to comment #10)
> This might get blamed as a very naive comment, but isn't this basically adding
> a list variable of all marked applications and iterating the
> installation/removal (and the dependency checks) for each app in that list?
Yes and no. :-)
There are two possibilities to handle multiple package in one go:
A) Do multiple operations, one for each package. This is exactly like
doing these operations individually in the UI, but requires less tapping.
This corresponds to
apt-get install foo
apt-get install bar
B) Setting up a single operation with all packages in it. This is
something you can't do from the UI, currently.
This corresponds to
apt-get install foo bar
These two possibilities are not equivalent when there are dependencies or
conflicts between foo and bar (directly or indirectly), so it is worthwhile to
think about which to choose.
The "Upgrade All" button does B). The reason for this is that apt isn't very
good with failing installs: if bar unexpectedly fails to install in the middle
(out of space, conflicting content, maintainer script failing, ...), the
installation of foo is likely to not be completed either, although it probably
could be. So we just upgrade them one by one.
The downside is that sometimes packages need to be upgraded together, and HAM
isn't good at all at doing that.
I think the best option is to go with B, improve HAM to deal better with
installing/removing/upgrading mutually depending/conflicting user-visible
packages, and to fix our packages so that they can be handled as independendly
(There was a case on the list recently about two user-visible packages
depending on a common library with "lib (= version)". HAM can not upgrade
them. We should fix HAM to handle that, _and_ we should fix the packages to be
*** Bug 6328 has been marked as a duplicate of this bug. ***
*** Bug 7810 has been marked as a duplicate of this bug. ***
For the record, there is a Brainstorm proposal:
Related discussion thread: http://talk.maemo.org/showthread.php?t=40086
However, I will keep the enhancement request here since it's an old one, with
good debate already. I was chasing the team for an answer before the holidays,
will try again now.
There is a new package that has been developed, called 'Faster Application
Manager' ( http://maemo.org/packages/view/fapman/ )
This application does the exact same thing the maemo application manager does,
but it's much faster and gives the end-user the ability to select multiple
packages to install/uninstall/update (even to select which packages to update
and which not to instead of just having 'Update All' button)
(In reply to comment #15)
> This application does the exact same thing the maemo application manager does
It doesn't. HAM has much more stricter policy about conflicts than apt-get (and
fapman is "just" a gui to apt-get)
I think its moot now. People who know what they are doing and/or are willing
to take risks, use fapman. Everyone else, use the default.
The default app manager is a slow piece of junk that makes the whole ui stutter
at times. Not only that but it lacks such basic comonsese functions that it's
nothing short of a big embaressment. Fapman is the only fumctional alternative.
please stop, this is a bugtracker, not a forum....
The Maemo 5 User Interface and Maemo 5 platform components (e.g. libraries)
used for the N900 are considered stable by Nokia and it seems that there are no
plans for official updates currently, hence nobody plans to work on this
(And in case you feel like discussing this situation: Nokia Customer Care or
http://talk.maemo.org would be the place to do so as you will not reach Nokia
officials in this community bugtracker - though all of this is really no news.)
Reflecting this status by setting RESOLVED WONTFIX for this
enhancement/wishlist request (see
https://bugs.maemo.org/page.cgi?id=fields.html#status for status explanations).
There is a small chance for issues in those Maemo components that are open
source: Contributed patches could be included and made available in the Maemo 5
Community CSSU updates.
The Maemo CSSU project is run by a small team of volunteers; see
http://wiki.maemo.org/CSSU for more information.
So in case that you can provide a patch that fixes the reported problem, please
feel encouraged to file a request under
Please note: The Maemo CSSU project is not related in any way to Nokia.
( Tag for mass-deleting bugmail: [cleanup20120324] )