RFC: add osso version of libtool and libatk

RFC: add osso version of libtool and libatk

[Robert Schuster]

[-- Attachment #1: Type: text/plain, Size: 319 bytes --]

Hi,
on IRC it was suggested to put this on the mailing list.

I want some osso versions (Maemo-specific) of some software packages in
OE to be able to build compatible packages:

http://bugs.openembedded.org/show_bug.cgi?id=3384

If no one objects I would like to apply the patches there.

Regards
Robert


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: RFC: add osso version of libtool and libatk

[Richard Purdie]

On Tue, 2008-01-08 at 13:29 +0100, Robert Schuster wrote:
> on IRC it was suggested to put this on the mailing list.
> 
> I want some osso versions (Maemo-specific) of some software packages in
> OE to be able to build compatible packages:
> 
> http://bugs.openembedded.org/show_bug.cgi?id=3384
> 
> If no one objects I would like to apply the patches there.

I have two concerns:

a) libtool at least duplicates a lot of recipe, we should be encouraging
more .inc usage.
b) packages is becoming large and unwieldy

There could be a case for splitting packages into say:

packages/ 
packages-gpe/
packages-maemo/
packages-openmoko/
packages-opie/

Sadly these two points don't work well together since .inc/patch sharing
with collections enabled doesn't work. This is something I think we need
to fix as a priority.

The advantage to b) is I can then remove groups of files from the
equation easily and speed up parsing and reduce the chances of bad
things like  maemo packages breaking my normal ones...

This disadvantage is that you end up with libtool in two places and if
one is updated, the other could be missed.

Reluctantly I'd therefore say it could be committed now if an .inc file
is created for libtool and maybe improved for atk but we should consider
the wider issue.

I'd also make a case for given vendor 'hacked' versions a
DEFAULT_PREFERENCE = "-1" so you have to explicitly select them.

Cheers,

Richard

Re: RFC: add osso version of libtool and libatk

[Robert Schuster]

[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]

Hi,
with Holger's help I pulled out an old version of libtool 1.5.6. I added
it to the tree again with DEFAULT_PREFERENCE = "-1" and a note for why
it exists ...

I'll have a look at unifying the libtool recipes later. They all look
very similar indeed ...

Regards
Robert

Richard Purdie schrieb:
> On Tue, 2008-01-08 at 13:29 +0100, Robert Schuster wrote:
>> on IRC it was suggested to put this on the mailing list.
>>
>> I want some osso versions (Maemo-specific) of some software packages in
>> OE to be able to build compatible packages:
>>
>> http://bugs.openembedded.org/show_bug.cgi?id=3384
>>
>> If no one objects I would like to apply the patches there.
> 
> I have two concerns:
> 
> a) libtool at least duplicates a lot of recipe, we should be encouraging
> more .inc usage.
> b) packages is becoming large and unwieldy
> 
> There could be a case for splitting packages into say:
> 
> packages/ 
> packages-gpe/
> packages-maemo/
> packages-openmoko/
> packages-opie/
> 
> Sadly these two points don't work well together since .inc/patch sharing
> with collections enabled doesn't work. This is something I think we need
> to fix as a priority.
> 
> The advantage to b) is I can then remove groups of files from the
> equation easily and speed up parsing and reduce the chances of bad
> things like  maemo packages breaking my normal ones...
> 
> This disadvantage is that you end up with libtool in two places and if
> one is updated, the other could be missed.
> 
> Reluctantly I'd therefore say it could be committed now if an .inc file
> is created for libtool and maybe improved for atk but we should consider
> the wider issue.
> 
> I'd also make a case for given vendor 'hacked' versions a
> DEFAULT_PREFERENCE = "-1" so you have to explicitly select them.
> 
> Cheers,
> 
> Richard
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: RFC: add osso version of libtool and libatk

[Holger Freyther]

On Tuesday 08 January 2008 13:29:15 Robert Schuster wrote:
> Hi,
> on IRC it was suggested to put this on the mailing list.

Hey,
I don't like adding vendor hacked versions of standard software at all. I see 
the requirement you are facing but adding a Nokia hacked version is not the 
right way to do it.

What are the differences you see? Can you extract the patch that is doing 
that? Is that patch a good idea and can be applied to our version of libtool?


kind regards
	z.


PS: I care more for libtool than atk+ (did they break API/ABI compability on 
it?) 

Re: RFC: add osso version of libtool and libatk

[Stanislav Brabec]

Holger Freyther wrote:
> On Tuesday 08 January 2008 13:29:15 Robert Schuster wrote:
> > Hi,
> > on IRC it was suggested to put this on the mailing list.
> 
> Hey,
> I don't like adding vendor hacked versions of standard software at all. I see 
> the requirement you are facing but adding a Nokia hacked version is not the 
> right way to do it.
> 
> What are the differences you see? Can you extract the patch that is doing 
> that? Is that patch a good idea and can be applied to our version of libtool?

Can you tell me what is the purpose of this patch? I looked into 15000
lines of the atk patch and cannot find any single change except adding
debian directory (not needed for OE) and modifying or adding of
auto-generated files (documentation, config.* and marshalls).

I am not able to find any single change in the code.

-- 
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: RFC: add osso version of libtool and libatk

[Holger Freyther]

On Tuesday 08 January 2008 15:59:50 Stanislav Brabec wrote:
> Can you tell me what is the purpose of this patch? I looked into 15000
> lines of the atk patch and cannot find any single change except adding
> debian directory (not needed for OE) and modifying or adding of
> auto-generated files (documentation, config.* and marshalls).
>
> I am not able to find any single change in the code.

I briefly talked with Robert on IRC. The requirement is not to use the osso 
variant but the upstream version. For libtool this is 1.5.6 and for atk 
probably the same applies.

My conclusion is there is nothing wrong with (re)adding the versions with a 
DEFAULT_PREFERENCE="-1" and I asked him to proceed.

z.

Re: RFC: add osso version of libtool and libatk

[pHilipp Zabel]

On Jan 8, 2008 6:08 PM, Holger Freyther <zecke@selfish.org> wrote:
> On Tuesday 08 January 2008 15:59:50 Stanislav Brabec wrote:
> > Can you tell me what is the purpose of this patch? I looked into 15000
> > lines of the atk patch and cannot find any single change except adding
> > debian directory (not needed for OE) and modifying or adding of
> > auto-generated files (documentation, config.* and marshalls).
> >
> > I am not able to find any single change in the code.
>
> I briefly talked with Robert on IRC. The requirement is not to use the osso
> variant but the upstream version. For libtool this is 1.5.6 and for atk
> probably the same applies.
>
> My conclusion is there is nothing wrong with (re)adding the versions with a
> DEFAULT_PREFERENCE="-1" and I asked him to proceed.

If the those are the unpatched upstream versions, and they are older than the
latest versions in OE, is the DEFAULT_PREFERENCE even needed?

regards
Philipp

Re: RFC: add osso version of libtool and libatk

[Stanislav Brabec]

Holger Freyther wrote:

> > I am not able to find any single change in the code.
> 
> I briefly talked with Robert on IRC. The requirement is not to use the osso 
> variant but the upstream version. For libtool this is 1.5.6 and for atk 
> probably the same applies.
> 
> My conclusion is there is nothing wrong with (re)adding the versions with a 
> DEFAULT_PREFERENCE="-1" and I asked him to proceed.

If I understand it correctly, it was really intended to only
re-libtoolize the package with the libtool version supporting maemo.

If it is true, calling libtoolize -f (or autoreconf -f -i) in the recipe
is a much cleaner solution.

It may be valid for more packages and more platforms.

-- 
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: RFC: add osso version of libtool and libatk

[Holger Freyther]

On Tuesday 08 January 2008 19:03:50 Stanislav Brabec wrote:
> If I understand it correctly, it was really intended to only
> re-libtoolize the package with the libtool version supporting maemo.
>
> If it is true, calling libtoolize -f (or autoreconf -f -i) in the recipe
> is a much cleaner solution.

No it is not. Packages using autotools should inherit autotools which is
supposed to call autoreconf --install --force. :)

z.

PS: This is one of the places where OE really shines!

Re: RFC: add osso version of libtool and libatk

[Robert Schuster]

[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]

Hi,
I can live with the plain versions, too. For libtool I re-added 1.5.6 as
discussed on IRC. I will prepare a similar patch for atk.

Holger Freyther schrieb:
> On Tuesday 08 January 2008 13:29:15 Robert Schuster wrote:
>> Hi,
>> on IRC it was suggested to put this on the mailing list.
> 
> Hey,
> I don't like adding vendor hacked versions of standard software at all. I see 
> the requirement you are facing but adding a Nokia hacked version is not the 
> right way to do it.
> 
> What are the differences you see? Can you extract the patch that is doing 
> that? Is that patch a good idea and can be applied to our version of libtool?
> 
> 
> kind regards
> 	z.
> 
> 
> PS: I care more for libtool than atk+ (did they break API/ABI compability on 
> it?) 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]