public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: "Richard Purdie" <richard.purdie@linuxfoundation.org>
To: Khem Raj <raj.khem@gmail.com>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>,
	Trevor Gamblin <trevor.gamblin@windriver.com>
Subject: Re: [OE-core] [PATCH 1/2 v5] coreutils: add ptest
Date: Mon, 06 Apr 2020 17:47:49 +0100	[thread overview]
Message-ID: <bbcedb53a9f5c5515acb5760237c5d3fe1f01e61.camel@linuxfoundation.org> (raw)
In-Reply-To: <CAMKF1so-A14JBx3CBAed2+zeBYN_Z8khPAMiXhcwT4HO-ZdsGg@mail.gmail.com>

On Mon, 2020-04-06 at 07:32 -0700, Khem Raj wrote:
> On Mon, Apr 6, 2020 at 4:58 AM Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> > On Sun, 2020-04-05 at 17:26 -0700, Khem Raj wrote:
> > > On Wed, Mar 11, 2020 at 4:33 AM Trevor Gamblin
> > > <trevor.gamblin@windriver.com> wrote:
> > > > +inherit ptest
> > > > +
> > > > +RDEPENDS_${PN}-ptest += "bash findutils gawk liberror-perl libmodule-build-perl make perl perl-module-file-stat python3-core sed shadow"
> > > > +
> > > 
> > > Adding libmodule-build-perl to rdeps here is pulling in whole target
> > > toolchain components now while building core-image-minimal
> > > the dependency chain looks like, total task building for this image are 3000+
> > > 
> > > "coreutils.do_package_qa" -> "libmodule-build-perl.do_packagedata" ->
> > > "packagegroup-core-buildessential.do_packagedata" ->
> > > "gcc.do_packagedata"
> > > 
> > > IMO, it's a bad experience for the user when building a simple minimal
> > > image and it ends up building whole toolchain for target that
> > > eventually won't even
> > > be part of the image. perhaps make it dependent on ptest or some such
> > > knob thats not commonly used.
> > > 
> > > Please revert this patch series until we can find a way to not insert
> > > these build-time dependencies in normal flow.
> > 
> > We were aware of this when it merged. This should already only happen
> > if ptest is enabled?
> > 
> 
> I am seeing it with a fresh checkout of poky with no other changes 

Poky enables ptest by default:

meta-poky/conf/distro/poky.conf:
POKY_DEFAULT_DISTRO_FEATURES = "largefile opengl ptest multiarch wayland vulkan"

so that is expected.

> > (else ${PN}-ptest isn't in PACKAGES and hence the RDEPENDS isn't seen).
> > 
> > I wish we had a better way of handling these dependencies but we sadly
> > don't.
> > 
> 
> Such changes should be left to users to enable imo may be a packageconfig or so 
> 
> People have reputation of long build times and large disk space for OE this won’t help that cause 

Well, I tried to have this conversation when the patch was being
reviewed and tested. Nobody seemed bothered then. I get tired of
talking to myself in a vacuum and having a reputation about being
difficult over patches when nobody seems to care (as no other voices
came into the conversation). I've tried to minimise the impact which
was the best we can do. We are trying to encourage people to add tests.

Starting to revert things just before release is a really bad idea so
we're not doing that.

We can disable ptest in coreutils specifically if we wanted. Ultimately
we need to find a better way in general of handling some of these
runtime dependencies but at this point that is a 3.2 issue.

Sorry, but if we were to have this discussion it should have been
months ago :(.

I'd also note that 3.1 rc1 is building now.

Cheers,

Richard


  reply	other threads:[~2020-04-06 16:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-11 11:32 [PATCH 0/2 v5] coreutils: add ptest support Trevor Gamblin
2020-03-11 11:32 ` [PATCH 1/2 v5] coreutils: add ptest Trevor Gamblin
2020-04-06  0:26   ` [OE-core] " Khem Raj
2020-04-06 11:58     ` Richard Purdie
2020-04-06 14:32       ` Khem Raj
2020-04-06 16:47         ` Richard Purdie [this message]
2020-04-07  2:26           ` Randy MacLeod
2020-03-11 11:32 ` [PATCH 2/2 v5] ptest-packagelists.inc: add coreutils to SLOW Trevor Gamblin

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=bbcedb53a9f5c5515acb5760237c5d3fe1f01e61.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=raj.khem@gmail.com \
    --cc=trevor.gamblin@windriver.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox