From: Martin Jansa <martin.jansa@gmail.com>
To: Khem Raj <raj.khem@gmail.com>
Cc: openembeded-devel <Openembedded-devel@lists.openembedded.org>,
Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] State of libcs in OE-Core glibc/uclibc/musl
Date: Fri, 30 Oct 2015 22:03:31 +0100 [thread overview]
Message-ID: <20151030210331.GE2566@jama> (raw)
In-Reply-To: <CAMKF1srB9b9iPF3WGyUeozOQdXi3DRa=BPx9CmtrM7VN_CAXeQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2107 bytes --]
On Fri, Oct 30, 2015 at 01:55:42PM -0700, Khem Raj wrote:
> On Fri, Oct 30, 2015 at 4:10 AM, Roman Khimov <roman@khimov.ru> wrote:
> > В письме от 29 октября 2015 08:42:31 пользователь Khem Raj написал:
> >> 1. Drop kconfig support in glibc and we become inline with upstream
> >
> > No opinion on this.
I agree, it can be outside oe-core and enabled + maintained by those who
care about it, it doesn't need to burden you Khem when you're doing all
glibc upgrades in oe-core.
> >> 2. Move musl support to OE-Core from meta-musl
> >
> > I would certainly support this kind of for musl.
I agree, it looks like more reasonable replacement for uclibc.
> >> 3. Drop uclibc or leave it in current broken state, I would like to pull it
> >> out into a layer in meta-openembedded and we can leave the core plumbing as
> >> it is in OE-Core
> >
> > But I don't think that moving uClibc out of OE Core is OK with the next
> > release. We do use it and there are probably some users too, I think it's
> > better to have a longer transition period for this kind of change, like make
> > the next release support three libcs and only move uClibc to meta-oe in a
> > subsequent release. This would give everyone some time to evaluate
> > alternatives rather than forcing to make choices right at the OE Core update
> > when usually there are lots of other things that need to be fixed.
>
> may be not a bad idea however, this still will be available as an
> independent layer on meta-openembedded
> but we could still keep it for a release
I agree again, few people are using it (based on recent survey from
Cliff), so having it in separate layer looks good to me.
> >
> >> 4. Poky-tiny switches to use musl
> >
> > No opinion on this.
I won't ever use poky-tiny, but switching it from glibc+kconfig to musl
would probably make it easier to do some build testing on Yocto AB, so
in the end it should improve test-coverage than current uclibc in
oe-core has.
Regards,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Martin Jansa <martin.jansa@gmail.com>
To: Khem Raj <raj.khem@gmail.com>
Cc: openembeded-devel <Openembedded-devel@lists.openembedded.org>,
Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: State of libcs in OE-Core glibc/uclibc/musl
Date: Fri, 30 Oct 2015 22:03:31 +0100 [thread overview]
Message-ID: <20151030210331.GE2566@jama> (raw)
In-Reply-To: <CAMKF1srB9b9iPF3WGyUeozOQdXi3DRa=BPx9CmtrM7VN_CAXeQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2107 bytes --]
On Fri, Oct 30, 2015 at 01:55:42PM -0700, Khem Raj wrote:
> On Fri, Oct 30, 2015 at 4:10 AM, Roman Khimov <roman@khimov.ru> wrote:
> > В письме от 29 октября 2015 08:42:31 пользователь Khem Raj написал:
> >> 1. Drop kconfig support in glibc and we become inline with upstream
> >
> > No opinion on this.
I agree, it can be outside oe-core and enabled + maintained by those who
care about it, it doesn't need to burden you Khem when you're doing all
glibc upgrades in oe-core.
> >> 2. Move musl support to OE-Core from meta-musl
> >
> > I would certainly support this kind of for musl.
I agree, it looks like more reasonable replacement for uclibc.
> >> 3. Drop uclibc or leave it in current broken state, I would like to pull it
> >> out into a layer in meta-openembedded and we can leave the core plumbing as
> >> it is in OE-Core
> >
> > But I don't think that moving uClibc out of OE Core is OK with the next
> > release. We do use it and there are probably some users too, I think it's
> > better to have a longer transition period for this kind of change, like make
> > the next release support three libcs and only move uClibc to meta-oe in a
> > subsequent release. This would give everyone some time to evaluate
> > alternatives rather than forcing to make choices right at the OE Core update
> > when usually there are lots of other things that need to be fixed.
>
> may be not a bad idea however, this still will be available as an
> independent layer on meta-openembedded
> but we could still keep it for a release
I agree again, few people are using it (based on recent survey from
Cliff), so having it in separate layer looks good to me.
> >
> >> 4. Poky-tiny switches to use musl
> >
> > No opinion on this.
I won't ever use poky-tiny, but switching it from glibc+kconfig to musl
would probably make it easier to do some build testing on Yocto AB, so
in the end it should improve test-coverage than current uclibc in
oe-core has.
Regards,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]
next prev parent reply other threads:[~2015-10-30 21:02 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-29 15:42 State of libcs in OE-Core glibc/uclibc/musl Khem Raj
2015-10-29 16:45 ` [oe] " Phil Blundell
2015-10-29 17:01 ` [OE-core] " Tim Orling
2015-10-29 20:09 ` Khem Raj
2015-10-29 20:20 ` Tim Orling
2015-10-29 17:28 ` Dan McGregor
2015-10-29 17:28 ` [oe] " Dan McGregor
2015-10-29 19:52 ` [OE-core] " Khem Raj
2015-10-29 19:52 ` [oe] " Khem Raj
2015-10-29 20:07 ` Mark Hatle
2015-10-29 20:07 ` [oe] " Mark Hatle
2015-10-29 20:14 ` [OE-core] " Khem Raj
2015-10-29 20:14 ` [oe] " Khem Raj
2015-10-29 20:26 ` [OE-core] " Mark Hatle
2015-10-29 20:26 ` [oe] " Mark Hatle
2015-10-30 0:26 ` [OE-core] " Khem Raj
2015-10-30 0:26 ` [oe] " Khem Raj
2015-10-30 11:10 ` [OE-core] " Roman Khimov
2015-10-30 11:10 ` Roman Khimov
2015-10-30 20:55 ` [OE-core] " Khem Raj
2015-10-30 20:55 ` Khem Raj
2015-10-30 21:03 ` Martin Jansa [this message]
2015-10-30 21:03 ` Martin Jansa
2015-10-30 16:21 ` [OE-core] " akuster808
2015-10-30 16:21 ` akuster808
2015-10-30 18:31 ` [OE-core] " Andre McCurdy
2015-10-30 18:31 ` [oe] " Andre McCurdy
2015-10-30 20:54 ` [OE-core] " Khem Raj
2015-10-30 20:54 ` [oe] " 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=20151030210331.GE2566@jama \
--to=martin.jansa@gmail.com \
--cc=Openembedded-devel@lists.openembedded.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=raj.khem@gmail.com \
/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.