From: "Richard Purdie" <richard.purdie@linuxfoundation.org>
To: Andre McCurdy <armccurdy@gmail.com>
Cc: Andrej Valek <andrej.valek@siemens.com>,
"openembedded-core@lists.openembedded.org"
<openembedded-core@lists.openembedded.org>,
Diego Sueiro <diego.sueiro@arm.com>
Subject: Re: [OE-core] [PATCH] busybox: add rev and pgrep
Date: Mon, 19 Oct 2020 21:10:24 +0100 [thread overview]
Message-ID: <c455d8210a548fb7dc5f81e9cd24a72980108c81.camel@linuxfoundation.org> (raw)
In-Reply-To: <CAJ86T=UNe-e5N9SLmwC=2Vto0og8aV-bmA2YF1dB9bV3R1Ujxw@mail.gmail.com>
On Mon, 2020-10-19 at 13:04 -0700, Andre McCurdy wrote:
> On Mon, Oct 19, 2020 at 12:57 PM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Mon, 2020-10-19 at 12:55 -0700, Andre McCurdy wrote:
> > > On Mon, Oct 19, 2020 at 6:25 AM Richard Purdie
> > > <richard.purdie@linuxfoundation.org> wrote:
> > > > On Fri, 2020-10-16 at 16:48 +0000, Andrej Valek wrote:
> > > > > Why are you not enabling these configs correctly via
> > > > > defconfig?
> > > >
> > > > I'd wondered about that. I didn't really want to block the
> > > > fixes on
> > > > that discussion and am trying to pick the best places for
> > > > discussion
> > > > but I'd take patches tweaking this.
> > >
> > > It would be good to clarify this. At one stage the advice was
> > > "the
> > > more fragmented the better". Does that no longer apply?
> > >
> > > https://lists.openembedded.org/g/openembedded-core/topic/72273944#68672
> > >
> >
> > The fragments need to be useful. We could create a fragment per
> > config
> > option but that would clearly not be particularly useful/usable.
> > Its a
> > question of common sense, which is hard to document explicitly :/.
>
> We have individual config fragments for sha1 and sha256 based on your
> advice in 2015. Has that been useful or usable?
I said I was torn, there was a second opinion that the fragments in
question were useful so we ran with that. I didn't say "the more the
better". My comment was specifically directed at keeping the login
pieces separate which I do still believe is the right move.
The distro situation was different 5 years ago, it would be interesting
to see if any layers did end up overriding the checksum pieces. If they
didn't, they likely can be merged IMO. Or maybe there should be one
checksum fragment with our defaults in?
Cheers,
Richard
prev parent reply other threads:[~2020-10-19 20:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-15 5:46 [PATCH] busybox: add rev and pgrep akuster
2020-10-15 9:07 ` Diego Sueiro
2020-10-16 16:48 ` [OE-core] " Andrej Valek
2020-10-19 13:25 ` Richard Purdie
2020-10-19 19:55 ` Andre McCurdy
2020-10-19 19:57 ` Richard Purdie
2020-10-19 20:04 ` Andre McCurdy
2020-10-19 20:10 ` Richard Purdie [this message]
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=c455d8210a548fb7dc5f81e9cd24a72980108c81.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=andrej.valek@siemens.com \
--cc=armccurdy@gmail.com \
--cc=diego.sueiro@arm.com \
--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.