Bug 601 - should offer remove/install multiple packages at once
: should offer remove/install multiple packages at once
Status: RESOLVED WONTFIX
Product: Settings and Maintenance
Application manager
: 5.0-beta
: All Maemo
: Unspecified enhancement with 96 votes (vote)
: ---
Assigned To: unassigned
: application-manager-bugs
:
: ITOS2007HE-garage
:
:
  Show dependency tree
 
Reported: 2006-06-18 15:24 UTC by Fionn Behrens
Modified: 2012-03-24 11:42 UTC (History)
16 users (show)

See Also:


Attachments
osso-application-installer 4.21 (78.47 KB, application/x-debian-package)
2006-06-19 10:57 UTC, Marius Vollmer
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description Fionn Behrens (reporter) 2006-06-18 15:24:26 UTC
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.
Comment 1 Fionn Behrens (reporter) 2006-06-18 15:27:40 UTC
For a start, the Application Installer could at least have some indicator
(maybe
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.
Comment 2 Marius Vollmer nokia 2006-06-19 10:57:54 UTC
Created an attachment (id=77) [details]
osso-application-installer 4.21
Comment 3 Marius Vollmer nokia 2006-06-19 10:58:53 UTC
Sorry attached the package to wrong bug...
Comment 4 Marius Vollmer nokia 2006-06-19 11:07:27 UTC
(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.
Comment 5 Jake Kunnari 2007-07-05 14:36:03 UTC
Quim added to cc-field
Comment 7 Andre Klapper maemo.org 2008-11-01 23:49:40 UTC
*** Bug 3837 has been marked as a duplicate of this bug. ***
Comment 8 Quim Gil nokia 2009-01-08 16:55:22 UTC
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?
Comment 9 Quim Gil nokia 2009-01-25 00:54:32 UTC
fwiw this feature is missing in the current Fremantle build. Applications ned
to be removd/installed ine by one as usual.
Comment 10 Andre Klapper maemo.org 2009-06-15 12:56:28 UTC
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?

Patches welcome.
Code is at
http://gitorious.org/hildon-application-manager/mainline/trees/master
Comment 11 Marius Vollmer nokia 2009-06-15 15:01:26 UTC
(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
as possible.

(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
more independent.)
Comment 12 Vladimir Baus 2009-11-25 14:51:41 UTC
*** Bug 6328 has been marked as a duplicate of this bug. ***
Comment 13 Andre Klapper maemo.org 2010-01-11 21:58:05 UTC
*** Bug 7810 has been marked as a duplicate of this bug. ***
Comment 14 Quim Gil nokia 2010-01-11 22:04:14 UTC
For the record, there is a Brainstorm proposal:

http://maemo.org/community/brainstorm/view/improving_app-manager-download-install_basket-002/

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.
Comment 15 Julien Chalhoub 2010-07-27 21:34:57 UTC
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)
Comment 16 ossipena 2010-07-27 23:40:16 UTC
(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)
Comment 17 Alex Atkin UK 2010-07-28 04:37:31 UTC
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.
Comment 18 Pelau Vadim 2010-07-29 20:46:07 UTC
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.
Comment 19 ossipena 2010-07-29 21:05:19 UTC
please stop, this is a bugtracker, not a forum....
Comment 20 Andre Klapper maemo.org 2012-03-24 11:42:40 UTC
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
enhancement/wishlist request. 
(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
https://bugs.maemo.org/enter_bug.cgi?product=Maemo%205%20Community%20SSU .
Please note: The Maemo CSSU project is not related in any way to Nokia.


( Tag for mass-deleting bugmail: [cleanup20120324] )