From: "Rasmus Villemoes" <rasmus.villemoes@prevas.dk>
To: Richard Purdie <richard.purdie@linuxfoundation.org>,
openembedded-core@lists.openembedded.org
Cc: Adrian Bunk <bunk@stusta.de>
Subject: Re: [PATCH][dunfell] coreutils: don't split stdbuf to own package with single-binary
Date: Fri, 3 Jul 2020 11:29:32 +0200 [thread overview]
Message-ID: <ee34bd95-2dcf-cbea-2b3f-e5c11f95e5e2@prevas.dk> (raw)
In-Reply-To: <64b8f2c4fbc20ea866a83844d117816de59082dc.camel@linuxfoundation.org>
On 03/07/2020 11.19, Richard Purdie wrote:
> On Fri, 2020-07-03 at 09:36 +0200, Rasmus Villemoes wrote:
>> Commit 992cec44 (coreutils: Move stdbuf into an own package
>> coreutils-stdbuf) breaks package-qa when the single-binary
>> PACKAGECONFIG is used:
>>
>> ERROR: coreutils-8.31-r0 do_package_qa: QA Issue: /usr/bin/stdbuf
>> contained in package coreutils-stdbuf requires /usr/bin/coreutils,
>> but no providers found in RDEPENDS_coreutils-stdbuf? [file-rdeps]
>> ERROR: coreutils-8.31-r0 do_package_qa: QA run found fatal errors.
>> Please consider fixing them.
>
> Does this problem exist for other packages in coreutils?
What other packages? stdbuf is the only one being split to its own package:
coreutils/8.31-r0$ ls -l packages-split/
total 32
drwxr-xr-x 4 ravi abcdef 4096 Jul 3 09:49 coreutils
drwxr-xr-x 3 ravi abcdef 4096 Jul 3 09:50 coreutils-dbg
drwxr-xr-x 2 ravi abcdef 4096 Jul 3 09:49 coreutils-dev
drwxr-xr-x 3 ravi abcdef 4096 Jul 3 09:49 coreutils-doc
drwxr-xr-x 2 ravi abcdef 4096 Jul 3 09:49 coreutils-locale
-rw-r--r-- 1 ravi abcdef 48 Jul 3 09:49 coreutils.shlibdeps
drwxr-xr-x 3 ravi abcdef 4096 Jul 3 09:50 coreutils-src
drwxr-xr-x 2 ravi abcdef 4096 Jul 3 09:49 coreutils-staticdev
> I'd suspect it
> does in which case why is stdbuf special?
Because it's the only util that gets special packaging treatment. Unless
there's some magic 'please auto-split all utils to their own packages'
that I don't know about and which we don't happen to set.
> Whilst I realise there is a problem here is the correct fix not:
>
> RDEPENDS_coreutils-stdbuf_class-target += "${@bb.utils.contains('PACKAGECONFIG', 'single-binary', '', 'coreutils', d)}"
>
> ?
[Well, the coreutils should be in the true branch of that.] I dunno, it
creates a cyclic rdepends between coreutils and coreutils-stdbuf. Is
that ok? Seems a bit ugly to me, even if it would work.
> As Alex says, this would need to be merged in master before we can even
> consider it for dunfell.
I'll do it for master once I know which way you want to fix it.
Rasmus
next prev parent reply other threads:[~2020-07-03 9:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-03 7:36 [PATCH][dunfell] coreutils: don't split stdbuf to own package with single-binary Rasmus Villemoes
2020-07-03 8:17 ` [OE-core] " Alexander Kanavin
2020-07-03 9:19 ` Richard Purdie
2020-07-03 9:29 ` Rasmus Villemoes [this message]
2020-07-03 10:48 ` Richard Purdie
2020-07-03 11:51 ` Rasmus Villemoes
2020-07-04 21:10 ` Adrian Bunk
2020-07-06 7:49 ` Rasmus Villemoes
-- strict thread matches above, loose matches on Subject: below --
2020-07-09 7:06 [PATCH] [dunfell] " Rasmus Villemoes
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=ee34bd95-2dcf-cbea-2b3f-e5c11f95e5e2@prevas.dk \
--to=rasmus.villemoes@prevas.dk \
--cc=bunk@stusta.de \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox