Thread (18 messages) 18 messages, 9 authors, 2012-03-27

Re: [PATCH] giflib: Move to OE-Core

From: Denys Dmytriyenko <hidden>
Date: 2012-03-23 00:07:48

On Fri, Mar 23, 2012 at 12:27:07AM +0100, Andrea Adami wrote:
On Thu, Mar 22, 2012 at 4:58 PM, Saul Wold [off-list ref] wrote:
quoted
On 03/22/2012 02:41 AM, Samuel Stirtzel wrote:
quoted
2012/3/22 Koen Kooi[off-list ref]:
quoted

Op 22 mrt. 2012, om 09:48 heeft Samuel Stirtzel het volgende geschreven:
quoted
2012/3/21 Koen Kooi[off-list ref]:
quoted

Op 21 mrt. 2012, om 20:42 heeft Saul Wold het volgende geschreven:
quoted
On 03/21/2012 07:25 AM, Samuel Stirtzel wrote:
quoted
* 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...

-- 
Denys

quoted
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!

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

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help