[maemo-community] [GSoC 09] - Integrating Maemo in Open Embedded

[From: Kees Jongenburger]

On Sat, Apr 25, 2009 at 5:33 PM, Jeremiah Foster
<jeremiah at jeremiahfoster.com> wrote:
>
> On Apr 25, 2009, at 13:34, Kees Jongenburger wrote:
>
>> On Sat, Apr 25, 2009 at 1:21 PM, Kirtika Ruchandani
>> <kirtibr at gmail.com> wrote:
>>>> Also worth noting that we have some Zaurus people around and I/we
>>>> did look
>>>> at OE
>>>> for Mer but felt that we wanted more compatibility with maemo etc
>>>> to allow
>>>> access to things like "Extras".
>>>
>> Debian's packaging strategy if different from OE's in the sense that
>> the packaging system is intrusive.
>
> Well, I am not sure I agree with you here. Debian has designed
> packages to be un-intrusive. In fact debian requires pristine upstream
> source and only adds a debian directory. Then you build the deb on
> your system, or it gets built on debian's architecture and you install
> the deb for your architecture, but you can always choose to build from
> source with apt-get source. I don't see how this is intrusive - in
> fact, it is one of the least intrusive types of packaging especially
> compared to an RPM.
>
>> Therefore
>> a "good" debian packages contains a source .deb package and the
>> package can be created using debian tools.
>
> The resulting deb package built from source is a binary.
>
>>
>> Many packages created for Maemo are some mix of "proper" debian
>> packages , packages without corresponding sources
>> and packages that with corresponding sources that can not be
>> recompiled easily because the source package
>> was only created as part of the debianisation.
>
> Maemo policy currently does not _require_ sources to accompany a
> binary deb. Perhaps it should require sources to be uploaded with the
> deb?
I would feel even safer if the auto builder was a requirement so we know the
source and binaries match.

>
>> If the OE port is to
>> support the "extras" packages it needs to support
>> the binary packages "as-is(binary)". To be able to do that the OE
>> build would need to have the same base package names as the Maemo
>> packages(not such a big problem) but binary compatibility clearly
>> would not fit in the OE strategy where the packages
>> can be created for different architectures or optimized for different
>> processors.
>
> Not sure what you mean here Kees. Debian supports eight architectures
> officially, no reason why the maemo packages couldn't do the same, at
> least theoretically. We'd have to have the build sources from Nokia
> and a host of architectures to build them on, but still, it could be
> done.

Practice however is that developers neither have access to the "host" platform
(when you are not cross compiling) nor are able to change root components. We
must be talking about different things (Is Cortex-A8 a different arch
in your terms?)

>
>> In short it most certainly is hard to achieve this. The "easy" thing
>> is to find the sources and create a bb file for it and that is extra
>> work. So it is hard to make use of all the great packages created to
>> maemo-proper. Mer is very close to achieving that goal
>
> Mer is an excellent solution to this problem. Plus it has a hard
> working, dedicated community already with a proven, released product.
> This is what should be supported and extended IMHO.

Indeed I think that given Mer current approach it has great potential.
so Yes we should
try to support Mer as "targeted architecture" is that the right term for you? or
do you think Mer and Maemo are "the same" ?

It this not something to discuss on developers list?

Greetings