Mailing List Archive: Maemo: Community

[GSoC 09] - Integrating Maemo in Open Embedded

Index | Next | Previous | View Threaded

kirtibr at gmail

Apr 22, 2009, 3:33 AM

Post #1 of 13 (1067 views)
Permalink

[GSoC 09] - Integrating Maemo in Open Embedded

Hello everyone,

I am Kirtika Ruchandani, a Maemo-GSoC student this year working on
integrating Maemo in Open Embedded(OE) by creating a maemo image for the
N800/N810 in OE.

The project aim is to get a file-system image of maemo built in OE for the
N800/N810 with all the Maemo software stack components - including the
hildon UI environment. The work done for this will also include making the
platform itself portable - i.e. being able to port Maemo components for a
device over a given base, say angstrom.

I will be looking at the Poky port of Maemo, previous work done by my mentor
Florian Boor on this project, Mamona (which supports N800 in OE) and
Angstrom (to be studied as a base) to go about the porting work.

I am a second year under-graduate student at Indian Institute of
Technology, Madras (IIT-M) in India and my IRC and garage nickname is
rkirti.

--
Kirtika Ruchandani
Sophomore
Computer Science and Engineering
Indian Institute of Technology, Madras

http://www.cse.iitm.ac.in/~rkirti/maemo-oe/

qole.tablet at gmail

Apr 23, 2009, 2:53 PM

Post #2 of 13 (1034 views)
Permalink

Re: [GSoC 09] - Integrating Maemo in Open Embedded [In reply to]

I'm sure this is obvious, but I just want to be sure:

Please also look at the Mer project, since they are trying to build a Maemo
system, using only the open source pieces of Maemo. They are building their
system on Ubuntu, instead of OE, but their project might offer insight into
the problems you will encounter.

http://wiki.maemo.org/index.php?title=Mer

On Wed, Apr 22, 2009 at 3:33 AM, Kirtika Ruchandani <kirtibr [at] gmail>wrote:

> Hello everyone,
>
> I am Kirtika Ruchandani, a Maemo-GSoC student this year working on
> integrating Maemo in Open Embedded(OE) by creating a maemo image for the
> N800/N810 in OE.
>
> The project aim is to get a file-system image of maemo built in OE for the
> N800/N810 with all the Maemo software stack components - including the
> hildon UI environment. The work done for this will also include making the
> platform itself portable - i.e. being able to port Maemo components for a
> device over a given base, say angstrom.
>
> I will be looking at the Poky port of Maemo, previous work done by my
> mentor Florian Boor on this project, Mamona (which supports N800 in OE) and
> Angstrom (to be studied as a base) to go about the porting work.
>
>
> I am a second year under-graduate student at Indian Institute of
> Technology, Madras (IIT-M) in India and my IRC and garage nickname is
> rkirti.
>
>
>
>
> --
> Kirtika Ruchandani
> Sophomore
> Computer Science and Engineering
> Indian Institute of Technology, Madras
>
> http://www.cse.iitm.ac.in/~rkirti/maemo-oe/<http://www.cse.iitm.ac.in/%7Erkirti/maemo-oe/>
>
>
>
> _______________________________________________
> maemo-community mailing list
> maemo-community [at] maemo
> https://lists.maemo.org/mailman/listinfo/maemo-community
>
>

--
enthusiast, n. "One whose mind is wholly possessed and heated by what
engages it; one who is influenced by a peculiar fervor of mind; an ardent
and imaginative person."

david at dgreaves

Apr 24, 2009, 6:13 AM

Post #3 of 13 (1033 views)
Permalink

Re: [GSoC 09] - Integrating Maemo in Open Embedded [In reply to]

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".

There would be a *lot* of work in just repackaging software before you even
start to hack at any code.

David

Qole wrote:
> I'm sure this is obvious, but I just want to be sure:
>
> Please also look at the Mer project, since they are trying to build a
> Maemo system, using only the open source pieces of Maemo. They are
> building their system on Ubuntu, instead of OE, but their project might
> offer insight into the problems you will encounter.
>
> http://wiki.maemo.org/index.php?title=Mer
>
> On Wed, Apr 22, 2009 at 3:33 AM, Kirtika Ruchandani <kirtibr [at] gmail
> <mailto:kirtibr [at] gmail>> wrote:
>
> Hello everyone,
>
> I am Kirtika Ruchandani, a Maemo-GSoC student this year working on
> integrating Maemo in Open Embedded(OE) by creating a maemo image for
> the N800/N810 in OE.
>
> The project aim is to get a file-system image of maemo built in OE
> for the N800/N810 with all the Maemo software stack components -
> including the hildon UI environment. The work done for this will
> also include making the platform itself portable - i.e. being able
> to port Maemo components for a device over a given base, say angstrom.
>
> I will be looking at the Poky port of Maemo, previous work done by
> my mentor Florian Boor on this project, Mamona (which supports N800
> in OE) and Angstrom (to be studied as a base) to go about the
> porting work.
>
>
> I am a second year under-graduate student at Indian Institute of
> Technology, Madras (IIT-M) in India and my IRC and garage nickname
> is rkirti.
>
>
>
>
> --
> Kirtika Ruchandani
> Sophomore
> Computer Science and Engineering
> Indian Institute of Technology, Madras
>
> http://www.cse.iitm.ac.in/~rkirti/maemo-oe/
> <http://www.cse.iitm.ac.in/%7Erkirti/maemo-oe/>

--
"Don't worry, you'll be fine; I saw it work in a cartoon once..."
_______________________________________________
maemo-community mailing list
maemo-community [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-community

kees.jongenburger at gmail

Apr 24, 2009, 8:19 AM

Post #4 of 13 (1032 views)
Permalink

Re: [GSoC 09] - Integrating Maemo in Open Embedded [In reply to]

On Fri, Apr 24, 2009 at 3:13 PM, David Greaves <david [at] dgreaves> 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".
>
> There would be a *lot* of work in just repackaging software before you even
> start to hack at any code.

The benefits of having the code really ready to be hacked and ported are huge.
and I therefore really hope I can help on this project. Mer is an
other excellent and
but really different project with more focus on end-user usabilty v.s
core reusability :p

Greetings

>
> David
>
> Qole wrote:
>> I'm sure this is obvious, but I just want to be sure:
>>
>> Please also look at the Mer project, since they are trying to build a
>> Maemo system, using only the open source pieces of Maemo. They are
>> building their system on Ubuntu, instead of OE, but their project might
>> offer insight into the problems you will encounter.
>>
>> http://wiki.maemo.org/index.php?title=Mer
>>
>> On Wed, Apr 22, 2009 at 3:33 AM, Kirtika Ruchandani <kirtibr [at] gmail
>> <mailto:kirtibr [at] gmail>> wrote:
>>
>> � � Hello everyone,
>>
>> � � I am Kirtika Ruchandani, a Maemo-GSoC student this year working on
>> � � integrating Maemo in Open Embedded(OE) by creating a maemo image for
>> � � the N800/N810 in OE.
>>
>> � � The project aim is to get a file-system image of maemo built in OE
>> � � for the N800/N810 with all the Maemo software stack components -
>> � � including the hildon UI environment. The work done for this will
>> � � also include making the platform itself portable - i.e. being able
>> � � to port Maemo components for a device over a given base, say angstrom.
>>
>> � � I will be looking at the Poky port of Maemo, previous work done by
>> � � my mentor Florian Boor on this project, Mamona (which supports N800
>> � � in OE) and Angstrom (to be studied as a base) to go about the
>> � � porting work.
>>
>>
>> � � I am a second year under-graduate student at �Indian Institute of
>> � � Technology, Madras (IIT-M) in India and my IRC and garage nickname
>> � � is rkirti.
>>
>>
>>
>>
>> � � --
>> � � Kirtika Ruchandani
>> � � Sophomore
>> � � Computer Science and Engineering
>> � � Indian Institute of Technology, Madras
>>
>> � � http://www.cse.iitm.ac.in/~rkirti/maemo-oe/
>> � � <http://www.cse.iitm.ac.in/%7Erkirti/maemo-oe/>
>
> --
> "Don't worry, you'll be fine; I saw it work in a cartoon once..."
> _______________________________________________
> maemo-community mailing list
> maemo-community [at] maemo
> https://lists.maemo.org/mailman/listinfo/maemo-community
>
_______________________________________________
maemo-community mailing list
maemo-community [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-community

david at dgreaves

Apr 24, 2009, 9:11 AM

Post #5 of 13 (1033 views)
Permalink

Re: [GSoC 09] - Integrating Maemo in Open Embedded [In reply to]

Kees Jongenburger wrote:
> On Fri, Apr 24, 2009 at 3:13 PM, David Greaves <david [at] dgreaves> 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".
>>
>> There would be a *lot* of work in just repackaging software before you even
>> start to hack at any code.
>
> The benefits of having the code really ready to be hacked and ported are huge.
> and I therefore really hope I can help on this project. Mer is an
> other excellent and
> but really different project with more focus on end-user usabilty v.s
> core reusability :p

I'm not sure it is as different as you think :)

Mer is about providing a distribution for small form factor and touch devices.
It is being designed to run on multiple hardware configurations.

I think the OE target is the tighter space of true embedded environments - think
Qtopia and memory/storage measured in 10s/100s MB.

Mer, maemo (and hildon) are more aimed at devices (like the internet tablets)
which have no problems running 'real' OSes but which benefit hugely from close
power management and UI enhancements. Here we use Xorg (and even OpenGL) and
measure RAM/storage in 100sMB/GBs.

Most of the previous/current and next-gen devices really fit in this category.

This means the compromises inherent in using .ipkg vs .deb hurt more than they
help... hence Mer's Ubunutu/OBS decision.

Now we are working on factoring out the hardware and platform specifics to allow
true multi-device support.

David

--
"Don't worry, you'll be fine; I saw it work in a cartoon once..."
_______________________________________________
maemo-community mailing list
maemo-community [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-community

S.G.Pickering at bath

Apr 24, 2009, 9:39 AM

Post #6 of 13 (1030 views)
Permalink

Re: [GSoC 09] - Integrating Maemo in Open Embedded [In reply to]

> This means the compromises inherent in using .ipkg vs .deb hurt more
> than they help... hence Mer's Ubunutu/OBS decision.

OE can equally build .deb's rather than .ipk's

I used the Maemo target a while back to build a few things (mainly
Octave and deps) and it was nice and painless, except for the fact
that some of the main dependencies had slightly different names (which
can confuse dpkg on the device when you try to install packages after
these ones).

> I think the OE target is the tighter space of true embedded
> environments - think
> Qtopia and memory/storage measured in 10s/100s MB.

OE is just meta-data, it can target whatever you want. I agree that
thus far it as tended to target low memory devices (mainly as that's
all that has been around thus far).

> Mer, maemo (and hildon) are more aimed at devices (like the internet tablets)
> which have no problems running 'real' OSes but which benefit hugely
> from close
> power management and UI enhancements. Here we use Xorg (and even OpenGL) and
> measure RAM/storage in 100sMB/GBs.

I see no reason why OE + bitbake couldn't be used to build such
images, except that work has already been done on the Debian build
environment and that afair the support for building for and from
Debian style files is still in its infancy.

I'm fully behind this project, I did a lot of work on and with the
Zaurus and thoroughly enjoyed using OE + bitbake.

Cheers,

Simon

_______________________________________________
maemo-community mailing list
maemo-community [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-community

cvm at cs

Apr 24, 2009, 10:47 AM

Post #7 of 13 (1030 views)
Permalink

Re: [GSoC 09] - Integrating Maemo in Open Embedded [In reply to]

Kees Jongenburger wrote:
> Mer is an other excellent and
> but really different project with more focus on end-user usabilty v.s
> core reusability :p
>
>
Just to get any misconceptions out of the way - Mer actually does focus
on core reusability, - we want Hildon and such to be portable, and
preferably straight from upstream, so we don't have any deltas to them,
- we have no interest in maintaining our own version of the Hildon
platform, other than building it for the distribution.
You can see http://wiki.maemo.org/Mer/Documentation/Common_packages for
our current status. Ideally we should have most packages being same
version, or with only deltas for Mer specific functionality or
compatibility.

We work on Mer not just to make Mer better, but to give the community a
possibility to make valuable contributions to the Maemo platform and a
place to experiment with new ideas, eventually easily adaptable to the
consumer-targeted Maemo OS.

When Fremantle beta comes out we will submit patches to Hildon and Maemo
software in order to improve portability (we have over 20+ weeks of work
to contribute) - such as removing Scratchbox-isms, assumptions on
existence of packages because they're in Scratchbox devkit, and other
things. This will improve the ability for anyone to take the Hildon
packages straight from Maemo and use them in their build/packaging
system, be it OE, Debian, Ubuntu, Gentoo, whereever.

I'm personally excited about the OpenEmbedded GSoC project, as it will
help putting the Maemo platform on more devices and platforms where Mer
for instance doesn't fit in so easily, and I'll do my part to help
rkirti with her project - with the knowledge gained through burying
ourselves deep in Maemo packages for over 20 weeks.

Stskeeps/Carsten V. Munk
Mer developer.

_______________________________________________
maemo-community mailing list
maemo-community [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-community

stephen.gadsby at gmail

Apr 24, 2009, 12:08 PM

Post #8 of 13 (1030 views)
Permalink

Re: [GSoC 09] - Integrating Maemo in Open Embedded [In reply to]

On Fri, Apr 24, 2009 at 1:47 PM, Carsten V. Munk <cvm [at] cs> wrote:
> You can see http://wiki.maemo.org/Mer/Documentation/Common_packages

There's a minor typo in this URL. It should be:
http://wiki.maemo.org/Mer/Documentation/Common_Packages

-stephen
_______________________________________________
maemo-community mailing list
maemo-community [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-community

kirtibr at gmail

Apr 25, 2009, 4:21 AM

Post #9 of 13 (1025 views)
Permalink

Re: [GSoC 09] - Integrating Maemo in Open Embedded [In reply to]

>
> 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.

Regards,

--
Kirtika Ruchandani
Sophomore
Computer Science and Engineering
Indian Institute of Technology, Madras

kees.jongenburger at gmail

Apr 25, 2009, 4:34 AM

Post #10 of 13 (1021 views)
Permalink

Re: [GSoC 09] - Integrating Maemo in Open Embedded [In reply to]

On Sat, Apr 25, 2009 at 1:21 PM, Kirtika Ruchandani <kirtibr [at] gmail> 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. Therefore
a "good" debian packages contains a source .deb package and the
package can be created using debian tools.

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. 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.

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

Greetings

>
> Regards,
>
> --
> Kirtika Ruchandani
> Sophomore
> Computer Science and Engineering
> Indian Institute of Technology, Madras
>
> _______________________________________________
> maemo-community mailing list
> maemo-community [at] maemo
> https://lists.maemo.org/mailman/listinfo/maemo-community
>
>
_______________________________________________
maemo-community mailing list
maemo-community [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-community

jeremiah at jeremiahfoster

Apr 25, 2009, 8:33 AM

Post #11 of 13 (1018 views)
Permalink

Re: [GSoC 09] - Integrating Maemo in Open Embedded [In reply to]

On Apr 25, 2009, at 13:34, Kees Jongenburger wrote:

> On Sat, Apr 25, 2009 at 1:21 PM, Kirtika Ruchandani
> <kirtibr [at] gmail> 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.

Jeremiah

_______________________________________________
maemo-community mailing list
maemo-community [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-community

kees.jongenburger at gmail

Apr 25, 2009, 9:17 AM

Post #12 of 13 (1029 views)
Permalink

Re: [GSoC 09] - Integrating Maemo in Open Embedded [In reply to]

On Sat, Apr 25, 2009 at 5:33 PM, Jeremiah Foster
<jeremiah [at] jeremiahfoster> 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> 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
_______________________________________________
maemo-community mailing list
maemo-community [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-community

jason at rampaginggeek

Apr 25, 2009, 11:12 AM

Post #13 of 13 (1013 views)
Permalink

Re: [GSoC 09] - Integrating Maemo in Open Embedded [In reply to]

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> 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
_______________________________________________
maemo-community mailing list
maemo-community [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-community

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads