Re[2]: Opie and OpenEmbedded

Hello Lorn,

Monday, October 30, 2006, 9:06:26 PM, you wrote:

> Paul Sokolovsky wrote:
>> Hello Michael,
>> 
>> Saturday, October 14, 2006, 1:43:11 PM, you wrote:
>> 
>> []
>> 
>>> I'd like to encourage someone of the active Opie developers
>>> to take care about everything Opie (and consequently Qt/Embedded)
>>> in OpenEmbedded.
>> 
>>   As promised, maintenance plan I would like to adhere to:
>> 
>> 1. Ensure that OPIE packages and rootfs builds correctly in OE.dev,
>> including working on support for new/different versions of GCC,
>> packaging peculiarities, etc.
>> 
>> 2. Work towards adding OPIE support in Angstrom.
>> 
>> 3. Working with port maintainers towards adding support for more
>> machines to OPIE.
>> 
>> 4. Work on establishing guidelines for machine support. In
>> particular, I'm not going to accept any patches blindly. Existing
>> machines support needs cleanup, too. Of course, this includes making
>> patches for libopie2 (at least), so I'm going to collaborate with OPIE
>> maintainers on that.

> see below.

>> 
>> 5. More higher-level and longer-term goal is getting rid of as much
>> machine-dependent packages for OPIE as possible. This might include
>> reworking means to support/configure different machines by means of
>> declarative configs, instead of being hardcoded into the C++ code.

> All of this is going to change with the upcoming qtopia 4 gpl release.
> Use the tag BEFORE_LJP_UPDATE because I plan on demolishing main.

   Thanks, noted. But I'm not going to make any jerky movements.
OPIE is at 1.2.2 in OE, seems to build/work nice modulo minor issues,
and no CVS-snaphot upgrades are planned, unless there're good reasons
for that (libopie2 is exactly the case when it's better to stay close
to HEAD, or, if interfaces will changes, to the tag you suggest).

> In Qtopia 4 (soon to be Opie II - or whatever people call it), there is
> a devices/ directory which can contain device specific code that gets 
> used in place of the default files in the tree. Configurable with 
> -device example

> like this:

> in devices/example/

[]

Seems like nice idea of "device plugins". Wonder, if they are
.so-able? Will need to have a look later.

> because every device is different. Its unnecessary to have every build
> have every device built in.

  Sure. I'd however like to make work in the direction of really similar
devices to get common support, not being supported each in adhoc way.
I already have some patches (well, still in my queue) to improve situation for
"ipaqs" (pocketpc's to be exact) support, and hope to adhere to this
line - work towards standard and consistent device support guidelines
- for my maintenance.

  Of course, I don't want to duplicate any effort here. Points 1-3
above will keep me busy for a month, at least, and I hope to that time
situation with the next Opie release will be more clear. If it will be
easy to port all apps to a new version, then indeed it will be nice to
put effort into supporting migration. If there will be contingencies,
well, we'll try to make OPIE 1.x be alive and well during the
transition...



-- 
Best regards,
 Paul                            mailto:[email protected]

_______________________________________________

http://opie.handhelds.org/cgi-bin/moin.cgi/DeveloperWikiIndex

Opie-devel mailing list
[email protected]
https://handhelds.org/mailman/listinfo/opie-devel