Message ID | 20240606122013.145187-1-Qi.Chen@windriver.com |
---|---|
State | Accepted, archived |
Commit | 7bc06eed72ceb55d2c5342e9130e39bd15c04b9a |
Headers | show |
Series | [1/2] coreutils: split out coreutils-getlimits | expand |
On 6 Jun 2024, at 13:20, Chen Qi via lists.openembedded.org <Qi.Chen=windriver.com@lists.openembedded.org> wrote: > > From: Chen Qi <Qi.Chen@windriver.com> > > Previously, the noinst_PROGRAM getlimits is put in coreutils-ptest > package in order to execute the ptest. However, this command might > also be needed by other ptest packages. As an example, findutils > 4.10.0 ptest pacakge would need this command. So we split it out > into a new package. Why would we not just put this in the main coreutils package? What’s so special about getlimits that it needs a standalone package? Ross
Because unlike other commands, getlimits is a noinst_PROGRAM. It's expected to be used by its tests only. I checked Ubuntu, Debian and Fedora, none of them provides getlimits. So if not for the ptest packages, we would not be using this command either. Regards, Qi -----Original Message----- From: Ross Burton <Ross.Burton@arm.com> Sent: Friday, June 7, 2024 9:34 PM To: Chen, Qi <Qi.Chen@windriver.com> Cc: openembedded-core@lists.openembedded.org Subject: Re: [OE-core][PATCH 1/2] coreutils: split out coreutils-getlimits On 6 Jun 2024, at 13:20, Chen Qi via lists.openembedded.org <Qi.Chen=windriver.com@lists.openembedded.org> wrote: > > From: Chen Qi <Qi.Chen@windriver.com> > > Previously, the noinst_PROGRAM getlimits is put in coreutils-ptest > package in order to execute the ptest. However, this command might > also be needed by other ptest packages. As an example, findutils > 4.10.0 ptest pacakge would need this command. So we split it out into > a new package. Why would we not just put this in the main coreutils package? What’s so special about getlimits that it needs a standalone package? Ross
On 7 Jun 2024, at 14:41, Chen Qi via lists.openembedded.org <Qi.Chen=windriver.com@lists.openembedded.org> wrote: > > Because unlike other commands, getlimits is a noinst_PROGRAM. It's expected to be used by its tests only. I checked Ubuntu, Debian and Fedora, none of them provides getlimits. So if not for the ptest packages, we would not be using this command either. So if nobody installs it, how does anyone else run the findutils test suite? Ross
For OE, the finduitls package before 4.10.0 does not require getlimits to run its ptest. But for the new 4.10.0 version, its test cases need getlimits. For other distros, I'm not sure if they have similar mechanisms like ptest and I'm not sure if they have met this problem. I just checked debian:latest and its finduitls package is of version 4.9.0. So chances are that they haven't met this problem or that their build system will not reveal such problem to them. Regards, Qi -----Original Message----- From: Ross Burton <Ross.Burton@arm.com> Sent: Friday, June 7, 2024 10:46 PM To: Chen, Qi <Qi.Chen@windriver.com> Cc: openembedded-core@lists.openembedded.org Subject: Re: [OE-core][PATCH 1/2] coreutils: split out coreutils-getlimits On 7 Jun 2024, at 14:41, Chen Qi via lists.openembedded.org <Qi.Chen=windriver.com@lists.openembedded.org> wrote: > > Because unlike other commands, getlimits is a noinst_PROGRAM. It's expected to be used by its tests only. I checked Ubuntu, Debian and Fedora, none of them provides getlimits. So if not for the ptest packages, we would not be using this command either. So if nobody installs it, how does anyone else run the findutils test suite? Ross
diff --git a/meta/recipes-core/coreutils/coreutils_9.5.bb b/meta/recipes-core/coreutils/coreutils_9.5.bb index 9a5f836ebe..178dadc3c5 100644 --- a/meta/recipes-core/coreutils/coreutils_9.5.bb +++ b/meta/recipes-core/coreutils/coreutils_9.5.bb @@ -76,6 +76,11 @@ RDEPENDS:coreutils:class-target += "${@bb.utils.contains('PACKAGECONFIG', 'singl # regardless of whether single-binary is in effect. RPROVIDES:coreutils += "${@bb.utils.contains('PACKAGECONFIG', 'single-binary', 'coreutils-stdbuf', '', d)}" +# put getlimits into coreutils-getlimits, because other ptest packages such as +# findutils-ptest may need this command. Note that getlimits is a noinst_PROGRAM +PACKAGE_BEFORE_PN:class-target += "${PN}-getlimits" +FILES:${PN}-getlimits = "${bindir}/getlimits" + # Let aclocal use the relative path for the m4 file rather than the # absolute since coreutils has a lot of m4 files, otherwise there might # be an "Argument list too long" error when it is built in a long/deep @@ -109,6 +114,9 @@ do_install:append() { # in update-alternatives to fail, therefore use lbracket - the name used # for the actual source file. mv ${D}${bindir}/[ ${D}${bindir}/lbracket.${BPN} + + # this getlimits noinst_PROGRAM would possibly be needed by other ptest packages + install ${B}/src/getlimits ${D}/${bindir} } inherit update-alternatives @@ -204,7 +212,6 @@ do_install_ptest () { # Tweak test d_type-check to use python3 instead of python sed -i "1s@.*@#!/usr/bin/python3@" ${D}${PTEST_PATH}/tests/d_type-check - install ${B}/src/getlimits ${D}/${bindir} # handle multilib sed -i s:@libdir@:${libdir}:g ${D}${PTEST_PATH}/run-ptest @@ -216,4 +223,4 @@ do_install_ptest:append:libc-musl () { sed -i -e '/tests\/dd\/no-allocate.sh/d' ${D}${PTEST_PATH}/Makefile sed -i -e '/tests\/split\/line-bytes.sh/d' ${D}${PTEST_PATH}/Makefile } -FILES:${PN}-ptest += "${bindir}/getlimits" +RDEPENDS:${PN}-ptest += "${PN}-getlimits"