[maemo-developers] Keeping Glib up to date

[From: josh.soref at nokia.com]

Graham Cobb wrote:
> I will create a bug for libxml2.

Good, that's productive.

> But, unfortunately, Nokia has got itself into a very 
> difficult position.  Of course, as a software developer,
> I embrace the principle of "don't fix it if it ain't broke".

This is just one deliverable. It isn't all deliverables.
Please don't blow one collection of updates out of proportion.

Perhaps we should have called it a "security update". Maybe,
Just Maybe, people would understand it for what it is.

> But Nokia wants Maemo to be a development platform, with a 
> community of developers.  It cannot do that if it LOCKS the 
> system into obsolete versions of important libraries.

Um... You're asserting that *all* releases of maemo will be
like this. Btw it's spelled "maemo", not "Maemo". People yell
at me when I mess up.

This was a service release, it was clearly described (marketed,
etc.) as such.

The next real release will almost certainly include a number of
major updates. E.g., the browser will likely move to something
very close to gecko1.9 (instead of gecko1.9 alpha 1).

> If Nokia wants to continue with the Internet Tablets being a 
> platform for a community of developers,

Nokia wants a product which customers will buy. One way to
enable this is to provide stability in features. Another is to
provide bleeding edge libraries. Most companies will generally
choose a middle ground.

I'm fairly certain that even Ubuntu does this. Certainly Debian does.

> it only has two reasonable choices:
> 1) Abandon the principle of "if it ain't broke..." and make a 
> commitment to keep all system libraries up to date. 

This definitely won't happen. There is and always will be a
drive from people toward the latest stable upstream, but we
can't make a commitment to use the latest.

> Clearly this will increase testing costs and also increase
> project risk (I used to be a development manager -- I 
> feel your pain). 

And increase scope. A big concern which you're clearly missing
is that it increases scope.

A service release where more than half of the components aren't
upgrade at all has a limited scope, and it means you don't have
to spend a noticable amount on testing those unchanged components.

> But, it can be done, if Nokia is willing to accept the 
> increased cost.

You're the only squeaky wheel I see here.

This may be my last post to this mailing list for months.

If it is, you will be the reason why.

> 2) Create a separate set of libraries (either nokiaglib, 
> nokiaxml2, etc or a /usr/nokia/lib directory) for
> Nokia-provided applications to use and release the lock
> on the community upgrading normal system libraries.

As it happens, the browser team does this (not correctly
because we poison the system search path, but we do it).

We're /usr/lib/microb-engine (relatively good)
and we're in /etc/ld.so.conf (problematic)
(and yes, I know people would prefer
/usr/microb-engine/{lib,share,etc,whatever}
however gecko has pathing behaviors and expects
a certain path structure, so this is the closest
we can get to it)

> I actually prefer option 2 because the problem is not only 
> keeping libraries up to date. 

Sadly this actually gets into trouble with certain other
management requirments because they want to be sure normal
systems behave in a standard manner. Providing an easy way
for non Nokia packages to break the world is not on the
requirements checklist. In fact, there's almost certainly a
line-item that asks for the opposite.

> For example (if I remember correctly), libopenobex in chinook 
> has been built without bluetooth support (or something like 
> that). 

This sounds strange.

http://timeless.justdave.net/mxr-test/os2008/source/libopenobex1-1.3osso
5/debian/patches/001_length_check.patch
http://timeless.justdave.net/mxr-test/os2008/source/libopenobex1-1.3osso
5/debian/patches/
http://timeless.justdave.net/mxr-test/chinook/source/libopenobex1-1.3oss
o5/debian/patches/

There's nothing remotely interesting in it.

> If Nokia are going to prevent us updating their libraries,
> I would prefer if their libraries did not have the same
> name as the real libraries.

I'm glad you prefer things. But really, while you are a person,
and while you may be a customer. And while Nokia would probably
like to have you buy another product. You are not the only
customer, and yet your assertions are written as if you are.

> I know Josh has suggested that the community do the opposite 
> of option 2 (e.g. create /usr/maemo/lib) but I do not think
> that is realistic or feasible. Nokia has both the incentive
> and the staff to do and maintain option 2.

Maybe. Probably not. The community is infinitely large.
Nokia is of finite size with limited resources and other
goals/requirements/tasks.

> The community does not.

The community can choose to do whatever it likes. It could
choose to build an evolving platform that replaces most of the
Nokia shipped components. In fact, I suspect that eventually
the community will choose to replace components. Hopefully
this would start with the ones for which there are no sources
and also the kernel (providing a standard updatable kernel
would be great). But eventually the community could provide
newer versions of the other libraries and a
completely unlocked system.

> And any solution has to apply to ALL 
> libraries (for example, what if Nokia suddenly decided to use,
> and ship, libsoup in the next release, suddenly turning it
> from an updateable to a locked library) and be fully
> integrated with the SDKs.  Only Nokia are realistically 
> in a position to do that.

> Otherwise, one (or, more likely, both) of two things will 
> happen: community support will decline (if I cant get
> Opensync to work I will start keeping a look out for an
> alternative toy for my next upgrade), or people will start to 
> bypass Nokia's locks, replacing core system libraries anyway, 
> and causing system instability.