[maemo-developers] Diablo, do we need a separate repository?

[From: Graham Cobb]

On Tuesday 06 May 2008 10:11:57 josh.soref at nokia.com wrote:
> I'm 99.99% certain that glib2.0 will be based on 2.12.12, just as it was
> in the previous release.

That is *very* disappointing.  Presumably Diablo is the last update until 2009 
at the earliest.  More and more applications cannot be built for Maemo just 
because they use features in glib introduced after 2.12.12.  It should ONLY 
be a testing issue to make sure glib is kept up to date in every release and 
it should be Nokia policy to keep it up to date unless it is discovered to 
break an application.

Don't forget: the community CANNOT update glib -- Nokia prevent that.  So, 
sticking with an out of date glib stops the community providing some 
applications.

Alternatively (and maybe better), if Nokia aren't willing to keep glib up to 
date they should rename it something else (nokiaglib) for their own apps and 
let the community build and install up to date versions of glib for community 
apps.

> Diablo is not a new OS. 

It is a new, updated, firmware installation.  Are you telling me that Nokia 
are actually testing that applications built against diablo work on 
(unupgraded) chinook systems?  Unless Nokia are testing that, there is a 
danger that there is a change which has not been noticed which means that 
some diablo applications do not work on chinook. 

I see no advantage at all to sharing a repository and a risk (possibly small) 
that it will come back to bite us.  I really don't see why anyone would 
bother to propose sharing a repository -- certainly anyone who lived through 
the mess of earlier point release Maemo updates.

> > (presumably Nokia does not allow a chinook
> > package to upgrade libssl)
>
> Wrong, as explained above. Both 0.9.7 and 0.9.8 are installed and owned
> by their own independent packages. Note that there is no
> /usr/lib/libssl.so, /usr/lib/libssl.so.0, nor /usr/lib/libssl.so.0.9
> only /usr/lib/libssl.so.0.9.7 and /usr/lib/libssl.so.0.9.8 - so there is
> no problem. An app that needs 0.9.8 simply writes:
>
> Build-Depends: libssl-dev (>= 0.9.8)
> Depends: libssl-dev
>
> An app that doesn't care writes:
> Build-Depends: libssl-dev
> Depends: libssl-dev
>
> The former will force the system to install libssl0.9.8 into chinook as
> part of the install. 

Has that been tested?  If so, that is good to know.  It means that I don't 
need to add a "diablo" distribution to my daily builds of GPE for the GPE 
development team.  But it still doesn't convince me that there could not be 
some other problem preventing diablo apps running on chinook.

> It does mean that the autobuilders should actually use chinook with
> repository access to diablo, otherwise the results will be things that
> aren't the most pleasant of experiences.

In general that doesn't work.  Even if the autobuilder continued to use the 
earlier SDK, it is possible that a community-contributed library might use 
some feature from the later release that would mean that a third app, which 
links against the library, doesn't work on the earlier release.

In this particular case, it might work.  If we are lucky.  And if Nokia 
conduct sufficient testing.  But why take the risk?  If we establish the 
principle now that every firmware update will be reflected in a new 
repository, and the contents will be autobuilt from the previous repository, 
we eliminate those risks at virtually no cost to the community and a 
considerable cost saving to Nokia (in testing).  That is the big benefit the 
autobuilder gives us.

In general, I would prefer that the autobuilder always uses the correct SDK 
for the target release.

Graham