Looking at Package Management for Karmic or Karmic+1

[Martin Olsson]

One gigantic improvement would be downloading package deltas
instead of whole .DEB files. I don't think this is necessarily that
hard to do in a reliable fashion. I assume you already thought
about that and it might be out of Ubuntu's scope (i.e. better
developed separately and then integrated into Ubuntu once it's
stable).

Another, much much simpler, feature request I have been thinking
about is to make installing updates faster by letting the download
and install parts run in parallel. With the current code I first
see my network capacity being maxed out with CPU and HDD activity
at nearly zero, then network activity stops and the machine starts
to tax the CPU and harddrive. Once a package plus it's dependencies
are downloaded, I don't see why that package cannot be allowed to
start it's installation / upgrade while the rest of the packages
are still being downloaded.


	Martin


Matthew Paul Thomas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Evan
> 
> Evan wrote on 31/03/09 23:19:
>> While apt, synaptic, update-manager, and gnome-app-install all do
>> decent jobs of providing front-ends for package management, there are
>> a few issues and common feature requests which bear taking a look at.
>> This is a strawman, so feel free to rip it apart as necessary.
> 
> In Canonical's Design and User Experience team we've just (this morning)
> started tackling the issue of package management in general, so your
> message is excellently timed.
> 
>> Modal Dialogues
>> All three of the GUIs currently use modal dialogues for the actual
>> download/install process, and this is considered a usability issue
>> AFAIK (I'm not a usability expert by any stretch of the imagination,
>> please correct me if I'm wrong).
> 
> You are quite correct: wherever a program has a modal progress window,
> it should be showing progress in the parent window instead. (See
> Thunderbird's "Sending Messages" and "Saving Messages" progress windows
> for more examples of how not to do it.)
> 
>>                                  I believe most people would like to
>> be able to continue browsing available applications, or reading
>> changelogs of updates while the packages are downloading and
>> installing.
> 
> Well, "most people" is debatable, but that's not a reason to make it
> impossible. It will just be a little tricky to implement.
> 
>> PolicyKit
>> Synaptic runs fully as root. Unless there is a specific reason not to,
>> should it not be migrated to PolicyKit?
>>
>> Queuing
>> The ability to start an install process, and then decide to queue
>> another app to install / update after the first is finished.
>>
>> Parallelism
>> Starting the install process in parallel with the download process as
>> soon as the first packages are finished downloading. (I got this idea
>> from brainstorm, but I can no longer find the relevant idea.)
> 
> All good ideas. I've added them to
> <https://wiki.ubuntu.com/AppCenter#Desired%20attributes>.
> 
>> I'm not sure what we ought to be changing or replacing, but I would
>> think we want to write a replacement for apt as the backend, and a
>> replacement for whatever provides the progress-bar in the GUI?
> 
> We'd need to get into a lot more design detail before deciding anything
> as fundamental as whether apt needs replacing.
> 
>> ...
>> The front end would display two progress bars, one for download and one
>> for installation.
> 
> Hopefully that isn't necessary. I shouldn't see two progress bars for
> something that, from my point of view, is a single task.
> 
>>                   It would also display a queue of what's to come
>> (perhaps with little Xs to cancel something if you change your mind).
>> It would be a seperate window in it's own right,
> 
> It wouldn't be necessary to put the queue in a separate window. It could
> be a viewable item in the main window, as it is in Miro for example.
> 
>>                                                  perhaps with the
>> ability to minize to tray.
>> ...
> 
> Unlikely. :-)
> 
> Thanks for your ideas. We'll be discussing this more in the coming
> weeks, so feel free to post more either here or on the wiki page.
> 
> Cheers
> - --
> Matthew Paul Thomas
> http://mpt.net.nz/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAknTeVkACgkQ6PUxNfU6ecq3lQCgv4cvut4GjIrBJxxEv3S/cQcb
> DQ8AnRpHqD5rJLM+sh7H9kwPtY8N92pt
> =/hZp
> -----END PGP SIGNATURE-----
>