Patchwork giflib: Move to OE-Core

login
register
mail settings
Submitter Samuel Stirtzel
Date March 21, 2012, 2:25 p.m.
Message ID <1332339926-27043-1-git-send-email-s.stirtzel@googlemail.com>
Download mbox | patch
Permalink /patch/24015/
State New
Headers show

Comments

Samuel Stirtzel - March 21, 2012, 2:25 p.m.
* This move will allow the testing of meta-kde for users without meta-openembedded.

Signed-off-by: Samuel Stirtzel <s.stirtzel@googlemail.com>
---
 meta/recipes-devtools/giflib/giflib_4.1.6.bb |   20 ++++++++++++++++++++
 1 files changed, 20 insertions(+), 0 deletions(-)
 create mode 100644 meta/recipes-devtools/giflib/giflib_4.1.6.bb
Saul Wold - March 21, 2012, 7:42 p.m.
On 03/21/2012 07:25 AM, Samuel Stirtzel wrote:
> * This move will allow the testing of meta-kde for users without meta-openembedded.
>
So what other layers are using giflib?

Your suggesting that we need to have it in oe-core so people don't need 
to add the meta-openembedded layer when using meta-kde?

I am just trying to get more data before making a decision.

Thanks
	Sau!


> Signed-off-by: Samuel Stirtzel<s.stirtzel@googlemail.com>
> ---
>   meta/recipes-devtools/giflib/giflib_4.1.6.bb |   20 ++++++++++++++++++++
>   1 files changed, 20 insertions(+), 0 deletions(-)
>   create mode 100644 meta/recipes-devtools/giflib/giflib_4.1.6.bb
>
> diff --git a/meta/recipes-devtools/giflib/giflib_4.1.6.bb b/meta/recipes-devtools/giflib/giflib_4.1.6.bb
> new file mode 100644
> index 0000000..bd7b495
> --- /dev/null
> +++ b/meta/recipes-devtools/giflib/giflib_4.1.6.bb
> @@ -0,0 +1,20 @@
> +DESCRIPTION = "shared library for GIF images"
> +SECTION = "libs"
> +LICENSE = "MIT"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=ae11c61b04b2917be39b11f78d71519a"
> +PR = "r2"
> +
> +SRC_URI = "${SOURCEFORGE_MIRROR}/giflib/${BP}.tar.bz2"
> +
> +inherit autotools
> +
> +DEPENDS = "libsm"
> +
> +PACKAGES += "${PN}-utils"
> +FILES_${PN} = "${libdir}/libgif.so.*"
> +FILES_${PN}-utils = "${bindir}"
> +
> +BBCLASSEXTEND = "native"
> +
> +SRC_URI[md5sum] = "7125644155ae6ad33dbc9fc15a14735f"
> +SRC_URI[sha256sum] = "e1c1ced9c5bc8f93ef0faf0a8c7717abf784d10a7b270d2285e8e1f3b93f2bed"
Koen Kooi - March 21, 2012, 8:14 p.m.
Op 21 mrt. 2012, om 20:42 heeft Saul Wold het volgende geschreven:

> On 03/21/2012 07:25 AM, Samuel Stirtzel wrote:
>> * This move will allow the testing of meta-kde for users without meta-openembedded.
>> 
> So what other layers are using giflib?
> 
> Your suggesting that we need to have it in oe-core so people don't need to add the meta-openembedded layer when using meta-kde?
> 
> I am just trying to get more data before making a decision.

Let's put everything in oe-core!
Richard Purdie - March 21, 2012, 8:27 p.m.
On Wed, 2012-03-21 at 21:14 +0100, Koen Kooi wrote:
> Op 21 mrt. 2012, om 20:42 heeft Saul Wold het volgende geschreven:
> 
> > On 03/21/2012 07:25 AM, Samuel Stirtzel wrote:
> >> * This move will allow the testing of meta-kde for users without meta-openembedded.
> >> 
> > So what other layers are using giflib?
> > 
> > Your suggesting that we need to have it in oe-core so people don't need to add the meta-openembedded layer when using meta-kde?
> > 
> > I am just trying to get more data before making a decision.
> 
> Let's put everything in oe-core!

Let's try and be constructive ;-).

I think to make a good decision about this we need to understand which
layers use giflib. 

Is this really the only component from meta-oe that meta-kde needs? If
it is, I think the request is certainly worth thinking about as we do
want to try and minimise and untangle the dependency spider web if we
can.

Cheers,

Richard
Robert Yang - March 22, 2012, 3:22 a.m.
On 03/22/2012 04:27 AM, Richard Purdie wrote:
> On Wed, 2012-03-21 at 21:14 +0100, Koen Kooi wrote:
>> Op 21 mrt. 2012, om 20:42 heeft Saul Wold het volgende geschreven:
>>
>>> On 03/21/2012 07:25 AM, Samuel Stirtzel wrote:
>>>> * This move will allow the testing of meta-kde for users without meta-openembedded.
>>>>
>>> So what other layers are using giflib?
>>>
>>> Your suggesting that we need to have it in oe-core so people don't need to add the meta-openembedded layer when using meta-kde?
>>>
>>> I am just trying to get more data before making a decision.
>>
>> Let's put everything in oe-core!
>
> Let's try and be constructive ;-).
>
> I think to make a good decision about this we need to understand which
> layers use giflib.
>
> Is this really the only component from meta-oe that meta-kde needs? If

Yes, as far as we know, this is the only component from meta-oe that
meta-kde needs.

// Robert

> it is, I think the request is certainly worth thinking about as we do
> want to try and minimise and untangle the dependency spider web if we
> can.
>
> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Denys Dmytriyenko - March 22, 2012, 3:36 a.m.
On Thu, Mar 22, 2012 at 11:22:42AM +0800, Robert Yang wrote:
> 
> 
> On 03/22/2012 04:27 AM, Richard Purdie wrote:
> >On Wed, 2012-03-21 at 21:14 +0100, Koen Kooi wrote:
> >>Op 21 mrt. 2012, om 20:42 heeft Saul Wold het volgende geschreven:
> >>
> >>>On 03/21/2012 07:25 AM, Samuel Stirtzel wrote:
> >>>>* This move will allow the testing of meta-kde for users without meta-openembedded.
> >>>>
> >>>So what other layers are using giflib?
> >>>
> >>>Your suggesting that we need to have it in oe-core so people don't need to add the meta-openembedded layer when using meta-kde?
> >>>
> >>>I am just trying to get more data before making a decision.
> >>
> >>Let's put everything in oe-core!
> >
> >Let's try and be constructive ;-).
> >
> >I think to make a good decision about this we need to understand which
> >layers use giflib.
> >
> >Is this really the only component from meta-oe that meta-kde needs? If
> 
> Yes, as far as we know, this is the only component from meta-oe that
> meta-kde needs.

Are you talking about kdelibs/kdebase or the entire KDE world? Building any of 
the standard KDE apps (kdenetwork, kdemultimedia, etc.) will bring additional 
dependencies...
Khem Raj - March 22, 2012, 4:47 a.m.
On Wed, Mar 21, 2012 at 1:27 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Wed, 2012-03-21 at 21:14 +0100, Koen Kooi wrote:
>> Op 21 mrt. 2012, om 20:42 heeft Saul Wold het volgende geschreven:
>>
>> > On 03/21/2012 07:25 AM, Samuel Stirtzel wrote:
>> >> * This move will allow the testing of meta-kde for users without meta-openembedded.
>> >>
>> > So what other layers are using giflib?
>> >
>> > Your suggesting that we need to have it in oe-core so people don't need to add the meta-openembedded layer when using meta-kde?
>> >
>> > I am just trying to get more data before making a decision.
>>
>> Let's put everything in oe-core!
>
> Let's try and be constructive ;-).
>
> I think to make a good decision about this we need to understand which
> layers use giflib.
>
> Is this really the only component from meta-oe that meta-kde needs? If
> it is, I think the request is certainly worth thinking about as we do
> want to try and minimise and untangle the dependency spider web if we
> can.
>

I think this library could belong to OE-Core since its a library for GIF images
its currently used by EFL libs. Putting it in OE-Core would be a better thing
IMO since it seems common library

> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Robert Yang - March 22, 2012, 6:46 a.m.
On 03/22/2012 11:36 AM, Denys Dmytriyenko wrote:
> On Thu, Mar 22, 2012 at 11:22:42AM +0800, Robert Yang wrote:
>>
>>
>> On 03/22/2012 04:27 AM, Richard Purdie wrote:
>>> On Wed, 2012-03-21 at 21:14 +0100, Koen Kooi wrote:
>>>> Op 21 mrt. 2012, om 20:42 heeft Saul Wold het volgende geschreven:
>>>>
>>>>> On 03/21/2012 07:25 AM, Samuel Stirtzel wrote:
>>>>>> * This move will allow the testing of meta-kde for users without meta-openembedded.
>>>>>>
>>>>> So what other layers are using giflib?
>>>>>
>>>>> Your suggesting that we need to have it in oe-core so people don't need to add the meta-openembedded layer when using meta-kde?
>>>>>
>>>>> I am just trying to get more data before making a decision.
>>>>
>>>> Let's put everything in oe-core!
>>>
>>> Let's try and be constructive ;-).
>>>
>>> I think to make a good decision about this we need to understand which
>>> layers use giflib.
>>>
>>> Is this really the only component from meta-oe that meta-kde needs? If
>>
>> Yes, as far as we know, this is the only component from meta-oe that
>> meta-kde needs.
>
> Are you talking about kdelibs/kdebase or the entire KDE world? Building any of

I just meant the kdebase, a base kde desktop, the kde-workspace which
can start the kde by command "startkde".

// Robert

> the standard KDE apps (kdenetwork, kdemultimedia, etc.) will bring additional
> dependencies...
>
Martin Jansa - March 22, 2012, 6:59 a.m.
On Wed, Mar 21, 2012 at 09:47:43PM -0700, Khem Raj wrote:
> On Wed, Mar 21, 2012 at 1:27 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Wed, 2012-03-21 at 21:14 +0100, Koen Kooi wrote:
> >> Op 21 mrt. 2012, om 20:42 heeft Saul Wold het volgende geschreven:
> >>
> >> > On 03/21/2012 07:25 AM, Samuel Stirtzel wrote:
> >> >> * This move will allow the testing of meta-kde for users without meta-openembedded.
> >> >>
> >> > So what other layers are using giflib?
> >> >
> >> > Your suggesting that we need to have it in oe-core so people don't need to add the meta-openembedded layer when using meta-kde?
> >> >
> >> > I am just trying to get more data before making a decision.
> >>
> >> Let's put everything in oe-core!

And then again and again!

> >
> > Let's try and be constructive ;-).
> >
> > I think to make a good decision about this we need to understand which
> > layers use giflib.
> >
> > Is this really the only component from meta-oe that meta-kde needs? If
> > it is, I think the request is certainly worth thinking about as we do
> > want to try and minimise and untangle the dependency spider web if we
> > can.
> >
> 
> I think this library could belong to OE-Core since its a library for GIF images
> its currently used by EFL libs. Putting it in OE-Core would be a better thing
> IMO since it seems common library

FWIW: meta-efl depends on more stuff from meta-oe so moving giflib won't
remove meta-oe dependency from meta-efl.

Cheers,
Samuel Stirtzel - March 22, 2012, 8:48 a.m.
2012/3/21 Koen Kooi <koen@dominion.thruhere.net>:
>
> Op 21 mrt. 2012, om 20:42 heeft Saul Wold het volgende geschreven:
>
>> On 03/21/2012 07:25 AM, Samuel Stirtzel wrote:
>>> * This move will allow the testing of meta-kde for users without meta-openembedded.
>>>
>> So what other layers are using giflib?
>>
>> Your suggesting that we need to have it in oe-core so people don't need to add the meta-openembedded layer when using meta-kde?
>>
>> I am just trying to get more data before making a decision.
>
> Let's put everything in oe-core!

Otherwise it would require to maintain a redundant copy of giflib in meta-kde.
Alternative suggestions are welcome.


A grep shows that not many recipes depend on giflib:
-
samuel@s-stirtzel-linux:/work/oe-core/setup-scripts/sources$ grep -r 'giflib' *
meta-java/recipes-core/openjdk/openjdk-6-common.inc:DEPENDS = "giflib
libpng jpeg cups \
meta-java/recipes-core/icedtea/icedtea6-native.inc:
freetype-native zlib-native giflib-native jpeg-native \
meta-kde/recipes-kde-base/kdelibs4_git.bb:DEPENDS = "automoc4-native
strigi libdbusmenu-qt soprano shared-desktop-ontologies dbus giflib
attica jpeg libpng bzip2 libpcre perl-native"
meta-openembedded/meta-efl/recipes-efl/efl/evas.inc:DEPENDS = "librsvg
eina eet freetype jpeg libpng virtual/libx11 libxext libxrender
fontconfig libfribidi giflib"
-

Any reason against the move?
Koen Kooi - March 22, 2012, 8:51 a.m.
Op 22 mrt. 2012, om 09:48 heeft Samuel Stirtzel het volgende geschreven:

> 2012/3/21 Koen Kooi <koen@dominion.thruhere.net>:
>> 
>> Op 21 mrt. 2012, om 20:42 heeft Saul Wold het volgende geschreven:
>> 
>>> On 03/21/2012 07:25 AM, Samuel Stirtzel wrote:
>>>> * This move will allow the testing of meta-kde for users without meta-openembedded.
>>>> 
>>> So what other layers are using giflib?
>>> 
>>> Your suggesting that we need to have it in oe-core so people don't need to add the meta-openembedded layer when using meta-kde?
>>> 
>>> I am just trying to get more data before making a decision.
>> 
>> Let's put everything in oe-core!
> 
> Otherwise it would require to maintain a redundant copy of giflib in meta-kde.

I don't think you get the concept of layers and keeping non-core stuff out of oe-core.

> Alternative suggestions are welcome.
> 
> 
> A grep shows that not many recipes depend on giflib:
> -
> samuel@s-stirtzel-linux:/work/oe-core/setup-scripts/sources$ grep -r 'giflib' *
> meta-java/recipes-core/openjdk/openjdk-6-common.inc:DEPENDS = "giflib
> libpng jpeg cups \
> meta-java/recipes-core/icedtea/icedtea6-native.inc:
> freetype-native zlib-native giflib-native jpeg-native \
> meta-kde/recipes-kde-base/kdelibs4_git.bb:DEPENDS = "automoc4-native
> strigi libdbusmenu-qt soprano shared-desktop-ontologies dbus giflib
> attica jpeg libpng bzip2 libpcre perl-native"
> meta-openembedded/meta-efl/recipes-efl/efl/evas.inc:DEPENDS = "librsvg
> eina eet freetype jpeg libpng virtual/libx11 libxext libxrender
> fontconfig libfribidi giflib"
> -
> 
> Any reason against the move?

The whole layering concept
Samuel Stirtzel - March 22, 2012, 9:41 a.m.
2012/3/22 Koen Kooi <koen@dominion.thruhere.net>:
>
> Op 22 mrt. 2012, om 09:48 heeft Samuel Stirtzel het volgende geschreven:
>
>> 2012/3/21 Koen Kooi <koen@dominion.thruhere.net>:
>>>
>>> Op 21 mrt. 2012, om 20:42 heeft Saul Wold het volgende geschreven:
>>>
>>>> On 03/21/2012 07:25 AM, Samuel Stirtzel wrote:
>>>>> * This move will allow the testing of meta-kde for users without meta-openembedded.
>>>>>
>>>> So what other layers are using giflib?
>>>>
>>>> Your suggesting that we need to have it in oe-core so people don't need to add the meta-openembedded layer when using meta-kde?
>>>>
>>>> I am just trying to get more data before making a decision.
>>>
>>> Let's put everything in oe-core!
>>
>> Otherwise it would require to maintain a redundant copy of giflib in meta-kde.
>
> I don't think you get the concept of layers and keeping non-core stuff out of oe-core.

How can it be that libpng is core stuff and libgif is not?

>
>> Alternative suggestions are welcome.
>>
>>
>> A grep shows that not many recipes depend on giflib:
>> -
>> samuel@s-stirtzel-linux:/work/oe-core/setup-scripts/sources$ grep -r 'giflib' *
>> meta-java/recipes-core/openjdk/openjdk-6-common.inc:DEPENDS = "giflib
>> libpng jpeg cups \
>> meta-java/recipes-core/icedtea/icedtea6-native.inc:
>> freetype-native zlib-native giflib-native jpeg-native \
>> meta-kde/recipes-kde-base/kdelibs4_git.bb:DEPENDS = "automoc4-native
>> strigi libdbusmenu-qt soprano shared-desktop-ontologies dbus giflib
>> attica jpeg libpng bzip2 libpcre perl-native"
>> meta-openembedded/meta-efl/recipes-efl/efl/evas.inc:DEPENDS = "librsvg
>> eina eet freetype jpeg libpng virtual/libx11 libxext libxrender
>> fontconfig libfribidi giflib"
>> -
>>
>> Any reason against the move?
>
> The whole layering concept
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Saul Wold - March 22, 2012, 3:58 p.m.
On 03/22/2012 02:41 AM, Samuel Stirtzel wrote:
> 2012/3/22 Koen Kooi<koen@dominion.thruhere.net>:
>>
>> Op 22 mrt. 2012, om 09:48 heeft Samuel Stirtzel het volgende geschreven:
>>
>>> 2012/3/21 Koen Kooi<koen@dominion.thruhere.net>:
>>>>
>>>> Op 21 mrt. 2012, om 20:42 heeft Saul Wold het volgende geschreven:
>>>>
>>>>> On 03/21/2012 07:25 AM, Samuel Stirtzel wrote:
>>>>>> * This move will allow the testing of meta-kde for users without meta-openembedded.
>>>>>>
>>>>> So what other layers are using giflib?
>>>>>
>>>>> Your suggesting that we need to have it in oe-core so people don't need to add the meta-openembedded layer when using meta-kde?
>>>>>
>>>>> I am just trying to get more data before making a decision.
>>>>
>>>> Let's put everything in oe-core!
>>>
>>> Otherwise it would require to maintain a redundant copy of giflib in meta-kde.
>>
>> I don't think you get the concept of layers and keeping non-core stuff out of oe-core.
>
> How can it be that libpng is core stuff and libgif is not?
>
libpng is in oe-core because it is used by other parts of oe-core (Sato, 
GTK+, Gthumb, Cups, ...).  PNG is also more common that GIF because GIF 
had licensing issues in the past.

Finally, as stated in other emails meta-kde has other dependencies on 
meta-oe, it's just the base bits that need giflib.

So, no we will not move libgif into oe-core, please use the Layers as 
they are intended.

Thanks
	Sau!

>>
>>> Alternative suggestions are welcome.
>>>
>>>
>>> A grep shows that not many recipes depend on giflib:
>>> -
>>> samuel@s-stirtzel-linux:/work/oe-core/setup-scripts/sources$ grep -r 'giflib' *
>>> meta-java/recipes-core/openjdk/openjdk-6-common.inc:DEPENDS = "giflib
>>> libpng jpeg cups \
>>> meta-java/recipes-core/icedtea/icedtea6-native.inc:
>>> freetype-native zlib-native giflib-native jpeg-native \
>>> meta-kde/recipes-kde-base/kdelibs4_git.bb:DEPENDS = "automoc4-native
>>> strigi libdbusmenu-qt soprano shared-desktop-ontologies dbus giflib
>>> attica jpeg libpng bzip2 libpcre perl-native"
>>> meta-openembedded/meta-efl/recipes-efl/efl/evas.inc:DEPENDS = "librsvg
>>> eina eet freetype jpeg libpng virtual/libx11 libxext libxrender
>>> fontconfig libfribidi giflib"
>>> -
>>>
>>> Any reason against the move?
>>
>> The whole layering concept
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
>
Andrea Adami - March 22, 2012, 11:27 p.m.
On Thu, Mar 22, 2012 at 4:58 PM, Saul Wold <sgw@linux.intel.com> wrote:
> On 03/22/2012 02:41 AM, Samuel Stirtzel wrote:
>>
>> 2012/3/22 Koen Kooi<koen@dominion.thruhere.net>:
>>>
>>>
>>> Op 22 mrt. 2012, om 09:48 heeft Samuel Stirtzel het volgende geschreven:
>>>
>>>> 2012/3/21 Koen Kooi<koen@dominion.thruhere.net>:
>>>>>
>>>>>
>>>>> Op 21 mrt. 2012, om 20:42 heeft Saul Wold het volgende geschreven:
>>>>>
>>>>>> On 03/21/2012 07:25 AM, Samuel Stirtzel wrote:
>>>>>>>
>>>>>>> * This move will allow the testing of meta-kde for users without
>>>>>>> meta-openembedded.
>>>>>>>
>>>>>> So what other layers are using giflib?
>>>>>>
>>>>>> Your suggesting that we need to have it in oe-core so people don't
>>>>>> need to add the meta-openembedded layer when using meta-kde?
>>>>>>
>>>>>> I am just trying to get more data before making a decision.
>>>>>
>>>>>
>>>>> Let's put everything in oe-core!
>>>>
>>>>
>>>> Otherwise it would require to maintain a redundant copy of giflib in
>>>> meta-kde.
>>>
>>>
>>> I don't think you get the concept of layers and keeping non-core stuff
>>> out of oe-core.
>>
>>
>> How can it be that libpng is core stuff and libgif is not?
>>
> libpng is in oe-core because it is used by other parts of oe-core (Sato,
> GTK+, Gthumb, Cups, ...).  PNG is also more common that GIF because GIF had
> licensing issues in the past.

All this seems to me unsatisfactory being that the above mentioned
'parts of OE' should not even be in oe-core.
About the specific .gif, .png , etc. libs, those should be in a
meta-graphics layer or whatever you want to call it.

Finally, nobody should feel guilty if not including meta-oe.
Developing a BSP is much easier with oe-core only (and no, the BSP
layers should not depend on meta-oe).

Just my 2 cents

Andrea

>
> Finally, as stated in other emails meta-kde has other dependencies on
> meta-oe, it's just the base bits that need giflib.
>
> So, no we will not move libgif into oe-core, please use the Layers as they
> are intended.
>
> Thanks
>        Sau!
>
>
>>>
>>>> Alternative suggestions are welcome.
>>>>
>>>>
>>>> A grep shows that not many recipes depend on giflib:
>>>> -
>>>> samuel@s-stirtzel-linux:/work/oe-core/setup-scripts/sources$ grep -r
>>>> 'giflib' *
>>>> meta-java/recipes-core/openjdk/openjdk-6-common.inc:DEPENDS = "giflib
>>>> libpng jpeg cups \
>>>> meta-java/recipes-core/icedtea/icedtea6-native.inc:
>>>> freetype-native zlib-native giflib-native jpeg-native \
>>>> meta-kde/recipes-kde-base/kdelibs4_git.bb:DEPENDS = "automoc4-native
>>>> strigi libdbusmenu-qt soprano shared-desktop-ontologies dbus giflib
>>>> attica jpeg libpng bzip2 libpcre perl-native"
>>>> meta-openembedded/meta-efl/recipes-efl/efl/evas.inc:DEPENDS = "librsvg
>>>> eina eet freetype jpeg libpng virtual/libx11 libxext libxrender
>>>> fontconfig libfribidi giflib"
>>>> -
>>>>
>>>> Any reason against the move?
>>>
>>>
>>> The whole layering concept
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>>
>>
>>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Denys Dmytriyenko - March 22, 2012, 11:58 p.m.
On Fri, Mar 23, 2012 at 12:27:07AM +0100, Andrea Adami wrote:
> On Thu, Mar 22, 2012 at 4:58 PM, Saul Wold <sgw@linux.intel.com> wrote:
> > On 03/22/2012 02:41 AM, Samuel Stirtzel wrote:
> >>
> >> 2012/3/22 Koen Kooi<koen@dominion.thruhere.net>:
> >>>
> >>>
> >>> Op 22 mrt. 2012, om 09:48 heeft Samuel Stirtzel het volgende geschreven:
> >>>
> >>>> 2012/3/21 Koen Kooi<koen@dominion.thruhere.net>:
> >>>>>
> >>>>>
> >>>>> Op 21 mrt. 2012, om 20:42 heeft Saul Wold het volgende geschreven:
> >>>>>
> >>>>>> On 03/21/2012 07:25 AM, Samuel Stirtzel wrote:
> >>>>>>>
> >>>>>>> * This move will allow the testing of meta-kde for users without
> >>>>>>> meta-openembedded.
> >>>>>>>
> >>>>>> So what other layers are using giflib?
> >>>>>>
> >>>>>> Your suggesting that we need to have it in oe-core so people don't
> >>>>>> need to add the meta-openembedded layer when using meta-kde?
> >>>>>>
> >>>>>> I am just trying to get more data before making a decision.
> >>>>>
> >>>>>
> >>>>> Let's put everything in oe-core!
> >>>>
> >>>>
> >>>> Otherwise it would require to maintain a redundant copy of giflib in
> >>>> meta-kde.
> >>>
> >>>
> >>> I don't think you get the concept of layers and keeping non-core stuff
> >>> out of oe-core.
> >>
> >>
> >> How can it be that libpng is core stuff and libgif is not?
> >>
> > libpng is in oe-core because it is used by other parts of oe-core (Sato,
> > GTK+, Gthumb, Cups, ...).  PNG is also more common that GIF because GIF had
> > licensing issues in the past.
> 
> All this seems to me unsatisfactory being that the above mentioned
> 'parts of OE' should not even be in oe-core.
> About the specific .gif, .png , etc. libs, those should be in a
> meta-graphics layer or whatever you want to call it.
> 
> Finally, nobody should feel guilty if not including meta-oe.
> Developing a BSP is much easier with oe-core only (and no, the BSP
> layers should not depend on meta-oe).

Ha, BSP layers _should not_, but sometimes they _have to_ depend on meta-oe:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/README

There's been extensive thread lately about this on meta-ti list...
Samuel Stirtzel - March 23, 2012, 8 a.m.
2012/3/23 Andrea Adami <andrea.adami@gmail.com>:
> On Thu, Mar 22, 2012 at 4:58 PM, Saul Wold <sgw@linux.intel.com> wrote:
>> On 03/22/2012 02:41 AM, Samuel Stirtzel wrote:
>>>
>>> 2012/3/22 Koen Kooi<koen@dominion.thruhere.net>:
>>>>
>>>>
>>>> Op 22 mrt. 2012, om 09:48 heeft Samuel Stirtzel het volgende geschreven:
>>>>
>>>>> 2012/3/21 Koen Kooi<koen@dominion.thruhere.net>:
>>>>>>
>>>>>>
>>>>>> Op 21 mrt. 2012, om 20:42 heeft Saul Wold het volgende geschreven:
>>>>>>
>>>>>>> On 03/21/2012 07:25 AM, Samuel Stirtzel wrote:
>>>>>>>>
>>>>>>>> * This move will allow the testing of meta-kde for users without
>>>>>>>> meta-openembedded.
>>>>>>>>
>>>>>>> So what other layers are using giflib?
>>>>>>>
>>>>>>> Your suggesting that we need to have it in oe-core so people don't
>>>>>>> need to add the meta-openembedded layer when using meta-kde?
>>>>>>>
>>>>>>> I am just trying to get more data before making a decision.
>>>>>>
>>>>>>
>>>>>> Let's put everything in oe-core!
>>>>>
>>>>>
>>>>> Otherwise it would require to maintain a redundant copy of giflib in
>>>>> meta-kde.
>>>>
>>>>
>>>> I don't think you get the concept of layers and keeping non-core stuff
>>>> out of oe-core.
>>>
>>>
>>> How can it be that libpng is core stuff and libgif is not?
>>>
>> libpng is in oe-core because it is used by other parts of oe-core (Sato,
>> GTK+, Gthumb, Cups, ...).  PNG is also more common that GIF because GIF had
>> licensing issues in the past.
>
> All this seems to me unsatisfactory being that the above mentioned
> 'parts of OE' should not even be in oe-core.
> About the specific .gif, .png , etc. libs, those should be in a
> meta-graphics layer or whatever you want to call it.

There is a layer called meta-multimedia, would giflib, libpng and the
others fit into it?

>
> Finally, nobody should feel guilty if not including meta-oe.
> Developing a BSP is much easier with oe-core only (and no, the BSP
> layers should not depend on meta-oe).
>
> Just my 2 cents
>
> Andrea
>
>>
>> Finally, as stated in other emails meta-kde has other dependencies on
>> meta-oe, it's just the base bits that need giflib.
>>
>> So, no we will not move libgif into oe-core, please use the Layers as they
>> are intended.
>>
>> Thanks
>>        Sau!
>>
>>
>>>>
>>>>> Alternative suggestions are welcome.
>>>>>
>>>>>
>>>>> A grep shows that not many recipes depend on giflib:
>>>>> -
>>>>> samuel@s-stirtzel-linux:/work/oe-core/setup-scripts/sources$ grep -r
>>>>> 'giflib' *
>>>>> meta-java/recipes-core/openjdk/openjdk-6-common.inc:DEPENDS = "giflib
>>>>> libpng jpeg cups \
>>>>> meta-java/recipes-core/icedtea/icedtea6-native.inc:
>>>>> freetype-native zlib-native giflib-native jpeg-native \
>>>>> meta-kde/recipes-kde-base/kdelibs4_git.bb:DEPENDS = "automoc4-native
>>>>> strigi libdbusmenu-qt soprano shared-desktop-ontologies dbus giflib
>>>>> attica jpeg libpng bzip2 libpcre perl-native"
>>>>> meta-openembedded/meta-efl/recipes-efl/efl/evas.inc:DEPENDS = "librsvg
>>>>> eina eet freetype jpeg libpng virtual/libx11 libxext libxrender
>>>>> fontconfig libfribidi giflib"
>>>>> -
>>>>>
>>>>> Any reason against the move?
>>>>
>>>>
>>>> The whole layering concept
>>>> _______________________________________________
>>>> Openembedded-core mailing list
>>>> Openembedded-core@lists.openembedded.org
>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Richard Purdie - March 23, 2012, 11:46 a.m.
On Fri, 2012-03-23 at 09:00 +0100, Samuel Stirtzel wrote:
> 2012/3/23 Andrea Adami <andrea.adami@gmail.com>:
> > On Thu, Mar 22, 2012 at 4:58 PM, Saul Wold <sgw@linux.intel.com> wrote:
> >> On 03/22/2012 02:41 AM, Samuel Stirtzel wrote:
> >>>
> >>> 2012/3/22 Koen Kooi<koen@dominion.thruhere.net>:
> >>>>
> >>>>
> >>>> Op 22 mrt. 2012, om 09:48 heeft Samuel Stirtzel het volgende geschreven:
> >>>>
> >>>>> 2012/3/21 Koen Kooi<koen@dominion.thruhere.net>:
> >>>>>>
> >>>>>>
> >>>>>> Op 21 mrt. 2012, om 20:42 heeft Saul Wold het volgende geschreven:
> >>>>>>
> >>>>>>> On 03/21/2012 07:25 AM, Samuel Stirtzel wrote:
> >>>>>>>>
> >>>>>>>> * This move will allow the testing of meta-kde for users without
> >>>>>>>> meta-openembedded.
> >>>>>>>>
> >>>>>>> So what other layers are using giflib?
> >>>>>>>
> >>>>>>> Your suggesting that we need to have it in oe-core so people don't
> >>>>>>> need to add the meta-openembedded layer when using meta-kde?
> >>>>>>>
> >>>>>>> I am just trying to get more data before making a decision.
> >>>>>>
> >>>>>>
> >>>>>> Let's put everything in oe-core!
> >>>>>
> >>>>>
> >>>>> Otherwise it would require to maintain a redundant copy of giflib in
> >>>>> meta-kde.
> >>>>
> >>>>
> >>>> I don't think you get the concept of layers and keeping non-core stuff
> >>>> out of oe-core.
> >>>
> >>>
> >>> How can it be that libpng is core stuff and libgif is not?
> >>>
> >> libpng is in oe-core because it is used by other parts of oe-core (Sato,
> >> GTK+, Gthumb, Cups, ...).  PNG is also more common that GIF because GIF had
> >> licensing issues in the past.
> >
> > All this seems to me unsatisfactory being that the above mentioned
> > 'parts of OE' should not even be in oe-core.
> > About the specific .gif, .png , etc. libs, those should be in a
> > meta-graphics layer or whatever you want to call it.
> 
> There is a layer called meta-multimedia, would giflib, libpng and the
> others fit into it?

I think people are focusing on libpng a little too much here.

libpng turns out to be an order of magnitude more important than giflib
due to the fact that pretty much any graphical UI uses them at this
point. To remove libpng from OE-Core we'd have to remove the X11 stack
and pretty much anything graphical (core gnome, QT and probably sdl and
directfb). That is not what we're trying to achieve in the core and not
in the best interests of OE.

giflib on the other hand is used more on the fringes of the system,
clearly demonstrated that we have a solid graphic core and don't need
it.

You can't just say "its a multimedia format so it belongs in
meta-multimedia" as you have to consider what depends on it and how
important it is in the overall web of dependencies.

I realise this situation is messy. Its a hard problem.

Cheers,

Richard
Khem Raj - March 27, 2012, 10:01 p.m.
On Fri, Mar 23, 2012 at 1:00 AM, Samuel Stirtzel
<s.stirtzel@googlemail.com> wrote:
> There is a layer called meta-multimedia, would giflib, libpng and the
> others fit into it?

From what you explained in another thread on its usage in KDE I think
its better to have a copy of it in meta-kde FWIW since if KDE switched
to using QT provided support for it then you can simply dump the recipe
and it will be fairly local change.

Patch

diff --git a/meta/recipes-devtools/giflib/giflib_4.1.6.bb b/meta/recipes-devtools/giflib/giflib_4.1.6.bb
new file mode 100644
index 0000000..bd7b495
--- /dev/null
+++ b/meta/recipes-devtools/giflib/giflib_4.1.6.bb
@@ -0,0 +1,20 @@ 
+DESCRIPTION = "shared library for GIF images"
+SECTION = "libs"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://COPYING;md5=ae11c61b04b2917be39b11f78d71519a"
+PR = "r2"
+
+SRC_URI = "${SOURCEFORGE_MIRROR}/giflib/${BP}.tar.bz2"
+
+inherit autotools
+
+DEPENDS = "libsm"
+
+PACKAGES += "${PN}-utils"
+FILES_${PN} = "${libdir}/libgif.so.*"
+FILES_${PN}-utils = "${bindir}"
+
+BBCLASSEXTEND = "native"
+
+SRC_URI[md5sum] = "7125644155ae6ad33dbc9fc15a14735f"
+SRC_URI[sha256sum] = "e1c1ced9c5bc8f93ef0faf0a8c7717abf784d10a7b270d2285e8e1f3b93f2bed"