[maemo-developers] External Repository and HAM

[From: Graham Cobb]

On Monday 08 March 2010 19:18:29 Aldon Hynes wrote:
> Personally, I like the idea of people setting up their own external
> repositories.  I've written about this in my blog post

I've read the post and it sounds great, except that that is not how 
repositories work, unfortunately.  What you want is multiple sources of apps, 
with people being able to choose where they want to get their apps from 
(vendors, communities, hackers, ones with support, ones where you are living 
on the bleeding edge, etc.).  Unfortunately neither DEB nor RPM can do that 
for you.

The biggest problem is shared resources.  To see the problem, assume that 
there is a library, libfoo, which provides a useful service, used by several 
apps, but which can be built with different options (there are many examples 
in real-life: security libraries support multiple encryption algorithms, 
sound libraries support multiple sound architectures, communications 
libraries support wired, wireless, etc).

Application A (from Apple, say) needs the libfoo service but only needs one 
option (call it the fruit option) enabled.  So, they build libfoo, with the 
fruit option enabled and put it in their repository, along with their 
application.

Application B (from a community called "Tea-time", say) also needs the libfoo 
service but they only need the "biscuit" option enabled.  So, they build 
libfoo, with the biscuit option enabled and put it in their repository, along 
with their application.

It is now impossible (with any package management system) to install both App 
A and App B on the same system as they both supply, and depend on, the same 
library file (libfoo.so) with different features.  And, of course, neither 
Apple nor Tea-time notice this because they only test their own apps.  The 
first person to notice the problem is some poor user (maybe months later) who 
wants to use both apps together.  How they see the problem, and how much 
information they get about the cause, will be dependent on what packaging 
system they use and other details like version numbers, but they **will** see 
a problem!

The solution to this, of course, is to build a version of libfoo with both the 
fruit and the biscuit options enabled.  But that raises a lot of questions:

1) Who builds it?  Neither Apple nor Tea-time have the incentive to do so. Who 
maintains it and who rebuilds it when App C wants to add the cake option?

2) Where does it live?  Both Apple and Tea-time want it in their repository as 
they don't want you to have to have the other repository enabled in order to 
download their app.

3) How do you make sure that when App C wants the cake option enabled, it 
doesn't break the fruit or biscuit options that A and B are relying on?

All these are **real** problems we experienced in the early days of Maemo and 
are the reasons we created the common repositories and put a LOT of pressure 
on developers to use them.  By having a common repository, there is always 
only one copy of the shared library, libfoo.  

Apple may create the first version, with just the fruit option enabled.  But 
when Tea-time create app B, they don't get to create their own library, they 
have to update libfoo and, if they have any sense at all, they just add the 
biscuit option and everyone is happy.  If they mess it up, then the first 
time App A is tested after libfoo has been broken, it will fail -- the 
problem can be found and quickly fixed.  And tools can be created (we haven't 
done this yet in Maemo but we could) to notify App A that libfoo (on which 
they depend) has been updated by someone else and they should retest to make 
sure they still work.

So, a long post why multiple repositories don't work.  If you want to give 
users a choice of "multiple app-stores" that is fine, but don't think it is 
done by allowing multiple repositories (I could write another long message 
about how you do do that -- basically you have things that are like 
repositories but only contain apps, no libraries allowed -- but it is a bit 
more complex than that in real life, of course).

Graham