All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denys Dmytriyenko <denis@denix.org>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] giflib: Move to OE-Core
Date: Thu, 22 Mar 2012 19:58:45 -0400	[thread overview]
Message-ID: <20120322235845.GD13495@denix.org> (raw)
In-Reply-To: <CAAQYJAtjfhhckJOTo1dxit4S72wFQ5Jt+r4MMfN6-Qu-Bw=DOg@mail.gmail.com>

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

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




  reply	other threads:[~2012-03-23  0:07 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-21 14:25 [PATCH] giflib: Move to OE-Core Samuel Stirtzel
2012-03-21 19:42 ` Saul Wold
2012-03-21 20:14   ` Koen Kooi
2012-03-21 20:27     ` Richard Purdie
2012-03-22  3:22       ` Robert Yang
2012-03-22  3:36         ` Denys Dmytriyenko
2012-03-22  6:46           ` Robert Yang
2012-03-22  4:47       ` Khem Raj
2012-03-22  6:59         ` Martin Jansa
2012-03-22  8:48     ` Samuel Stirtzel
2012-03-22  8:51       ` Koen Kooi
2012-03-22  9:41         ` Samuel Stirtzel
2012-03-22 15:58           ` Saul Wold
2012-03-22 23:27             ` Andrea Adami
2012-03-22 23:58               ` Denys Dmytriyenko [this message]
2012-03-23  8:00               ` Samuel Stirtzel
2012-03-23 11:46                 ` Richard Purdie
2012-03-27 22:01                 ` Khem Raj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120322235845.GD13495@denix.org \
    --to=denis@denix.org \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.