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

Denys Dmytriyenko denis at denix.org
Thu Mar 22 23:58:45 UTC 2012


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 at linux.intel.com> wrote:
> > On 03/22/2012 02:41 AM, Samuel Stirtzel wrote:
> >>
> >> 2012/3/22 Koen Kooi<koen at dominion.thruhere.net>:
> >>>
> >>>
> >>> Op 22 mrt. 2012, om 09:48 heeft Samuel Stirtzel het volgende geschreven:
> >>>
> >>>> 2012/3/21 Koen Kooi<koen at 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...

-- 
Denys


> > 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 at 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 at lists.openembedded.org
> >>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >>
> >>
> >>
> >>
> >
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core at lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core





More information about the Openembedded-core mailing list