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

[From: Jason Edgecombe]

Jeremiah Foster 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".
>>>>         
>>> @David:
>>> Its probably  *very* premature for me to be speaking at this point  
>>> about
>>> this - but I fail to understand why stuff like "Extras" should be a  
>>> problem
>>> with OE. IMHO, OE is designed to accomodate bringing new packages  
>>> easily -
>>> making it just a matter writing a small bb recipe - if the distro  
>>> confs are
>>> well-written.  But as I said, I probably don't get your point  
>>> because I
>>> haven't reached that  stage in my work as yet.
>>>       
>> 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?
>
>   
>> 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.
>
>   
>> 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.
>   
Both DEB and RPM formats allow for the pristine source to be included 
alongside the distro-specific patches. Best practice for both formats 
recommends this. Both formats can easily be abused to not include the 
pristine sources. Perhaps your alluding to specific abuse by some 
RPM-using entity or community, but from what I have read of both 
formats, both allow the pristine sources to be included. In fact, one 
could argue that debian is invasive because your typically unzip and 
rezip the source, whereas the RPM usually includes the pristine archive 
as-is inside the RPM source archive.

I've made packages in both, and I see them both as good formats. I use 
the appropriate format depending on which distro I'm targeting.

Sincerely,
Jason