Hi,

most of our prebuilt binaries (built outside OE, sometimes by other
companies) are built against libpng12.

Not because they must be, just because libpng12 was there when they started
building them and nobody revisited that since then. Now I'm trying to get
all those prebuilt binaries to be rebuilt against libpng 1.6 before we
upgrade to Yocto 2.4. If I don't get them soon enough I'll need to keep
libpng12 in one of our internal layer for a bit longer.

So I agree it's outdated waste of time, but unfortunately still mis-used by
some people.

Regards,

On Fri, Sep 15, 2017 at 10:25 AM, Andreas Müller <
[email protected]> wrote:

> On Fri, Sep 15, 2017 at 2:31 AM, Khem Raj <[email protected]> wrote:
> > On Thu, Sep 14, 2017 at 8:58 AM, Martin Jansa <[email protected]>
> wrote:
> >> If LSB isn't goal of oe-core, then why not move all this:
> >>
> >> OE qemux86-64@ ~/build/oe-core/openembedded-core $ find meta -name
> \*lsb\*
> >> meta/recipes-extended/images/core-image-lsb.bb
> >> meta/recipes-extended/images/core-image-lsb-dev.bb
> >> meta/recipes-extended/images/core-image-lsb-sdk.bb
> >> meta/recipes-extended/lsb
> >> meta/recipes-extended/lsb/lsb
> >> meta/recipes-extended/lsb/lsb/lsb_pidofproc
> >> meta/recipes-extended/lsb/lsb/lsb_start_daemon
> >> meta/recipes-extended/lsb/lsb/lsb_log_message
> >> meta/recipes-extended/lsb/lsb/0001-fix-lsb_release-to-work-
> with-busybox-head-and-find.patch
> >> meta/recipes-extended/lsb/lsb/lsb_killproc
> >> meta/recipes-extended/lsb/lsbinitscripts_9.72.bb
> >> meta/recipes-extended/lsb/lsbinitscripts
> >> meta/recipes-extended/lsb/lsbtest_1.0.bb
> >> meta/recipes-extended/lsb/lsb_4.1.bb
> >> meta/recipes-extended/lsb/lsbtest
> >> meta/recipes-extended/packagegroups/packagegroup-core-lsb.bb
> >> meta/lib/oe/__pycache__/lsb.cpython-35.pyc
> >> meta/lib/oe/__pycache__/lsb.cpython-36.pyc
> >> meta/lib/oe/lsb.pyc
> >> meta/lib/oe/lsb.py
> >>
> >> together with libpng12, to some new meta-lsb layer, preferably outside
> >> meta-oe repository as I already have enough of this stuff.
> >>
> >
> > A patch to remove them is good since you already found this out. If
> > they get into a layer of its own
> > can happen later when lsb interested devs chime in.
> >
> >> On Thu, Sep 14, 2017 at 5:03 PM, Burton, Ross <[email protected]>
> wrote:
> >>
> >>> On 14 September 2017 at 14:49, Alexander Kanavin
> <alexander.kanavin@linux.
> >>> intel.com> wrote:
> >>>
> >>>> On 09/14/2017 04:42 PM, Burton, Ross wrote:
> >>>>
> >>>>> On 14 September 2017 at 11:33, Martin Jansa <[email protected]>
> >>>>> wrote:
> >>>>>
> >>>>> LSB compliance isn't a goal of meta-oe as well, otherwise we'd need
> to
> >>>>>> add Qt4 to meta-oe too.
> >>>>>>
> >>>>>>
> >>>>> Touche.
> >>>>>
> >>>>> It still needs to go somewhere though...
> >>>>>
> >>>>
> >>>> How about modifying the LSB tests to make the absence of libpng12 a
> >>>> warning rather than an error?
> >>>>
> >>>
> >>> Then it won't be doing a LSB test...   The LSB is the LSB, we don't
> claim
> >>> to support it, but there's a need for a libpng12 recipe for people who
> want
> >>> to be close.  Currently it's just this one recipe that I'm aware of
> that
> >>> isn't already in a layer somewhere.
> >>>
> >>> Ross
> >>>
> One aspect I missed in this discussion: I there a recipe around
> depending on libpng12 which cannot use libpng 1.6?
> This is yet another case I get the the feeling that the priorities
> others have do not match mine: My topmost priority is to build working
> images and maintain them to keep them in working condition. Adding and
> maintaining recipes for sake of outdated standards is waste of time -
> at least for me.
>
> Andreas
>
-- 
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Reply via email to