| 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
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"
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!
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
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 >
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...
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
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... >
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,
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?
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
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
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 > > >
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
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...
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
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
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"
* 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