[maemo-developers] maemo-developers Digest, Vol 59, Issue 25

[From: Jeremiah Foster]

On Mar 26, 2010, at 9:36 AM, Marius Vollmer wrote:

> ext Urho Konttori <urho.konttori at gmail.com> writes:
> 
>> Also, the current model of centralized gigantic repository does not
>> scale up too well.  Just look at the state of using extras-devel is on
>> the current devices (hint: slow pain).
> 
> [ Urho, thanks for this opportunity to talk about how we want to make
>  package management kick ass again. 
> 
> The resources needed to maintain a centralized repository can be quite
> easily parallized to make the repository itself scale: there can be many
> buildbots, many mirrors, a CDN, many testers, and many maintainers.
> 
> Now, the repository infrastructure and the processes around it can suck,
> of course, and putting another better designed and maintained repository
> into place might be needed.  But that's only better because this other
> repository is better by itself; it's not better because we now have two
> of them.  Shutting down the original sucky repository would be better
> still (but might not be easy, of course).

One huge issue with the repository is the tool used on the backend: apt-ftparchiver. This tool cannot automatically remove debs and source packages, causing huge disk bloat (some packages have four or five versions sitting on the repos.)

I have tried to fix this by installing a set up for reprepro - a state of the art repository management system. This work has been largely ignored by the Nokia team running the repos, much to my frustration.
> 
> I believe there is a better way to make package management delightful:
> We only let HAM see a (consistent) subset of all available packages, and
> we make it possible to change that subset very efficiently at run-time
> (at "UI speed" without the need for any "Updating please wait" progress
> bars).
> 
> That subset would include only the installed packages plus the ones that
> the user is currently interested in.  Discovering packages that the user
> might be interested in is done without help from apt, via other means.
> 
> We are currently writing code for this.  We don't have all the pieces in
> place yet, but we have some:

The danger is of creating a fork of the APT process. Using upstream tools would probably be wise - your work would help everyone.

> 
> - The "x-apt" package in Fremantle extras-devel.  This is Harmattans
>   version of apt, repackaged to be installable in parallel to
>   Fremantle's version of apt.
> 
>   The modifications currently include support for "deb-exec" entries in
>   sources.list; this allows you to easily use custom protocols between
>   apt and repositories for downloading the Packages file, etc.
> 
>   Today I'll add the patch for storing the Maemo specific flags in
>   apt's binary cache.  This allows us to do our extra OS meta package
>   gymnastics without having to read the Packages files.
> 
>   http://maemo.gitorious.org/maemo-pkg/apt/commits/x-apt
> 
> - The "mini-pacman" library (not yet in extras-devel).  This is a
>   minimal wrapper of libapt-pkg, with a very simplistic API.  Of
>   course, it actually uses x-apt, not the platform apt.
> 
>   It is also the experimentation ground for different algorithms that
>   should get rid of some of the annoyances of the current HAM: better
>   error messages, updating the OS when that helps, more agressively in
>   general, etc.
> 
>   http://maemo.gitorious.org/maemo-af/mini-pacman/trees/master/src
> 
> - A maemo.org specific 'discovery client'.  It interfaces with
>   downloads.maemo.org over a custom protocol for browsing available
>   applications.  Right now it passes .install files to HAM for the
>   actual installation, and my plan is to hook it up with mini-pacman
>   instead and then optimize the hell out of the whole stack.
> 
>   (Haven't seen the code yet myself, Daniel Wilms and Niels Breet
>   should know more.)
> 
>> [...] I really do thing we have started to make our home our prison
> 
> Then we should remove the bars and locks.  Tearing down the whole house
> and going back up the trees would be overreacting quite a bit, no?

You'll need to allow the community to have more say on how the server infrastructure is run. Currently you need an NDA, proprietary tools are used, and access is strictly limited. This is the opposite of open source.

Jeremiah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.maemo.org/pipermail/maemo-developers/attachments/20100326/67597b2c/attachment.htm>