[meta-oe][PATCH v4 1/3] introduce lib_subpackage

[meta-oe][PATCH v4 1/3] introduce lib_subpackage

[Sinan Kaya]

This subclass allows us to easily split a recipe into
subpackages.

Signed-off-by: Sinan Kaya <okaya@kernel.org>
---
 meta/classes/lib_subpackage.bbclass | 40 +++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)
 create mode 100644 meta/classes/lib_subpackage.bbclass

diff --git a/meta/classes/lib_subpackage.bbclass b/meta/classes/lib_subpackage.bbclass
new file mode 100644
index 00000000000..a0c3d2446c7
--- /dev/null
+++ b/meta/classes/lib_subpackage.bbclass
@@ -0,0 +1,40 @@
+python __anonymous() {
+    packages = []
+
+    variables = [ ("base_sbindir_progs", "base_sbindir"),
+                  ("base_bindir_progs", "base_bindir"),
+                  ("bindir_progs", "bindir"),
+                  ("sbindir_progs", "sbindir"),
+                ]
+
+    for v in variables:
+        if d.getVar(v[0]) is None:
+            continue
+        for prog in d.getVar(v[0]).split():
+            pkg = "%s-%s" % (d.getVar("PN"), prog.replace("_", "-"))
+            packages.append(pkg)
+
+            # set alternatives
+            d.setVar("ALTERNATIVE_%s" % pkg, prog.replace("_", "-"))
+            d.setVarFlag('ALTERNATIVE_LINK_NAME', prog, '%s/%s' % (d.getVar(v[1]), prog))
+
+            d.setVar("RDEPENDS_%s" % pkg, "%s-lib" % d.getVar("PN"))
+            d.appendVar("FILES_%s" % pkg, " ${%s}/%s.%s" % (v[1], prog, d.getVar("BPN")))
+
+    pkg = "%s-man" % (d.getVar("PN"))
+    packages.append(pkg)
+    d.appendVar("FILES_%s" % pkg, " ${mandir}/*")
+
+    pkg = "%s-lib" % (d.getVar("PN"))
+    packages.append(pkg)
+    d.appendVar("FILES_%s" % pkg, " ${libdir}/*")
+
+    d.setVar("LIB_SUBPACKAGES_%s" % d.getVar("PN"), " ".join(packages))
+
+    d.setVar("FILES_%s" % d.getVar("PN"), "")
+    d.setVar("ALTERNATIVE_%s" % d.getVar("PN"), "")
+    d.setVar("ALLOW_EMPTY_%s" % d.getVar("PN"), "1")
+    d.appendVar("PACKAGES", " " + " ".join(packages))
+    d.appendVar("PROVIDES", " " + " ".join(packages))
+    d.appendVar("RRECOMMENDS_%s" % d.getVar("PN"), " " + " ".join(packages))
+}
-- 
2.17.1

[meta-oe][PATCH v4 2/3] net-tools: split into binary packages

[Sinan Kaya]

Support per binary package to not bloat the system with unneeded
tools.

Signed-off-by: Sinan Kaya <okaya@kernel.org>
---
 .../net-tools/net-tools_1.60-20181103.bb                 | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/meta/recipes-extended/net-tools/net-tools_1.60-20181103.bb b/meta/recipes-extended/net-tools/net-tools_1.60-20181103.bb
index e97731073e8..f9253123c24 100644
--- a/meta/recipes-extended/net-tools/net-tools_1.60-20181103.bb
+++ b/meta/recipes-extended/net-tools/net-tools_1.60-20181103.bb
@@ -21,6 +21,7 @@ UPSTREAM_VERSION_UNKNOWN = "1"
 S = "${WORKDIR}/git"
 
 inherit gettext
+inherit lib_subpackage
 
 # The Makefile is lame, no parallel build
 PARALLEL_MAKE = ""
@@ -93,18 +94,10 @@ base_bindir_progs  = "ifconfig netstat route \
     ${@bb.utils.contains('PACKAGECONFIG', 'hostname', 'dnsdomainname domainname hostname nisdomainname ypdomainname', '', d)} \
 "
 
-ALTERNATIVE_${PN} = "${base_sbindir_progs} ${base_bindir_progs}"
 ALTERNATIVE_${PN}-doc += "${@bb.utils.contains('PACKAGECONFIG', 'hostname', 'hostname.1 dnsdomainname.1', '', d)}"
 ALTERNATIVE_LINK_NAME[hostname.1] = "${mandir}/man1/hostname.1"
 ALTERNATIVE_LINK_NAME[dnsdomainname.1] = "${mandir}/man1/dnsdomainname.1"
 ALTERNATIVE_PRIORITY[hostname.1] = "10"
-
-python __anonymous() {
-    for prog in d.getVar('base_sbindir_progs').split():
-        d.setVarFlag('ALTERNATIVE_LINK_NAME', prog, '%s/%s' % (d.getVar('base_sbindir'), prog))
-    for prog in d.getVar('base_bindir_progs').split():
-        d.setVarFlag('ALTERNATIVE_LINK_NAME', prog, '%s/%s' % (d.getVar('base_bindir'), prog))
-}
 ALTERNATIVE_PRIORITY = "100"
 
 BBCLASSEXTEND = "native nativesdk"
-- 
2.17.1

[meta-oe][PATCH v4 3/3] procps: split into binary subpackages

[Sinan Kaya]

This change allows you to pull individual binaries into the
target without including the entire suite.

Signed-off-by: Sinan Kaya <okaya@kernel.org>
---
 meta/recipes-extended/procps/procps_3.3.16.bb | 15 ++++-----------
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/meta/recipes-extended/procps/procps_3.3.16.bb b/meta/recipes-extended/procps/procps_3.3.16.bb
index 2810ebd285a..efca33127a4 100644
--- a/meta/recipes-extended/procps/procps_3.3.16.bb
+++ b/meta/recipes-extended/procps/procps_3.3.16.bb
@@ -11,6 +11,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
 DEPENDS = "ncurses"
 
 inherit autotools gettext pkgconfig update-alternatives
+inherit lib_subpackage
 
 SRC_URI = "git://gitlab.com/procps-ng/procps.git;protocol=https \
            file://sysctl.conf \
@@ -50,27 +51,19 @@ do_install_append () {
 
 CONFFILES_${PN} = "${sysconfdir}/sysctl.conf"
 
-bindir_progs = "free pkill pmap pgrep pwdx skill snice top uptime w"
+bindir_progs = "free pkill pmap pgrep pwdx skill slabtop snice tload top uptime vmstat w"
 base_bindir_progs += "kill pidof ps watch"
 base_sbindir_progs += "sysctl"
 
 ALTERNATIVE_PRIORITY = "200"
 ALTERNATIVE_PRIORITY[pidof] = "150"
 
-ALTERNATIVE_${PN} = "${bindir_progs} ${base_bindir_progs} ${base_sbindir_progs}"
-
 ALTERNATIVE_${PN}-doc = "kill.1 uptime.1"
 ALTERNATIVE_LINK_NAME[kill.1] = "${mandir}/man1/kill.1"
 ALTERNATIVE_LINK_NAME[uptime.1] = "${mandir}/man1/uptime.1"
 
-python __anonymous() {
-    for prog in d.getVar('base_bindir_progs').split():
-        d.setVarFlag('ALTERNATIVE_LINK_NAME', prog, '%s/%s' % (d.getVar('base_bindir'), prog))
-
-    for prog in d.getVar('base_sbindir_progs').split():
-        d.setVarFlag('ALTERNATIVE_LINK_NAME', prog, '%s/%s' % (d.getVar('base_sbindir'), prog))
-}
-
 # 'ps' isn't suitable for use as a security tool so whitelist this CVE.
 # https://bugzilla.redhat.com/show_bug.cgi?id=1575473#c3
 CVE_CHECK_WHITELIST += "CVE-2018-1121"
+
+FILES_${PN}-sysctl_append = " ${sysconfdir}/sysctl.conf ${sysconfdir}/sysctl.d"
-- 
2.17.1

Re: [OE-core] [meta-oe][PATCH v4 1/3] introduce lib_subpackage

[Phil Blundell]

On Thu, Dec 03, 2020 at 11:28:24PM +0000, Sinan Kaya wrote:
> This subclass allows us to easily split a recipe into
> subpackages.

"lib_subpackage" seems a slightly odd name for something that isn't
dealing with libraries.  What's the etymology of that?

> +    d.appendVar("PACKAGES", " " + " ".join(packages))
> +    d.appendVar("PROVIDES", " " + " ".join(packages))

It seems a bit strange to be putting the same things in PACKAGES and
PROVIDES.  Is that actually necessary?

p.

Re: [OE-core] [meta-oe][PATCH v4 1/3] introduce lib_subpackage

[Sinan Kaya]

+Richard,

On 12/4/2020 6:01 AM, Phil Blundell via lists.openembedded.org wrote:
> On Thu, Dec 03, 2020 at 11:28:24PM +0000, Sinan Kaya wrote:
>> This subclass allows us to easily split a recipe into
>> subpackages.
> 
> "lib_subpackage" seems a slightly odd name for something that isn't
> dealing with libraries.  What's the etymology of that?

I'm open to giving it a better name. Richard pointed me to a file
beginning with lib_foo.class for where this functionality could be
hosted before.

> 
>> +    d.appendVar("PACKAGES", " " + " ".join(packages))
>> +    d.appendVar("PROVIDES", " " + " ".join(packages))
> 
> It seems a bit strange to be putting the same things in PACKAGES and
> PROVIDES.  Is that actually necessary?

I want to be able to include procps-ps without the entire procps
package. I was not able to do that without the above two lines.

> 
> p.
> 
> 
> 
> 
> 

Re: [OE-core] [meta-oe][PATCH v4 1/3] introduce lib_subpackage

[Phil Blundell]

On Fri, Dec 04, 2020 at 08:30:01AM -0500, Sinan Kaya wrote:
> +Richard,
> 
> On 12/4/2020 6:01 AM, Phil Blundell via lists.openembedded.org wrote:
> > On Thu, Dec 03, 2020 at 11:28:24PM +0000, Sinan Kaya wrote:
> >> This subclass allows us to easily split a recipe into
> >> subpackages.
> > 
> > "lib_subpackage" seems a slightly odd name for something that isn't
> > dealing with libraries.  What's the etymology of that?
> 
> I'm open to giving it a better name. Richard pointed me to a file
> beginning with lib_foo.class for where this functionality could be
> hosted before.

I suppose the interesting question here, then, is "what is this class
actually for?"  The description above says that it "allows us to easily
split a recipe into subpackages" but doesn't say very much about what
the consequences of including the class actually are or under what
circumstances that's useful.

Reading between the lines the idea seems to be that this class is
appropriate for recipes that build a collection of utilities each of
which is essentially independent and is useful in its own right
without any of the others.  Is that right?

> >> +    d.appendVar("PACKAGES", " " + " ".join(packages))
> >> +    d.appendVar("PROVIDES", " " + " ".join(packages))
> > 
> > It seems a bit strange to be putting the same things in PACKAGES and
> > PROVIDES.  Is that actually necessary?
> 
> I want to be able to include procps-ps without the entire procps
> package. I was not able to do that without the above two lines.

What do you mean by "include procps-ps"?  It sounds like you're saying
you want to be able to introduce procps-ps to DEPENDS, is that right?

p.

Re: [OE-core] [meta-oe][PATCH v4 1/3] introduce lib_subpackage

[Sinan Kaya]

On 12/5/2020 5:23 PM, Phil Blundell wrote:
>> I'm open to giving it a better name. Richard pointed me to a file
>> beginning with lib_foo.class for where this functionality could be
>> hosted before.
> I suppose the interesting question here, then, is "what is this class
> actually for?"  The description above says that it "allows us to easily
> split a recipe into subpackages" but doesn't say very much about what
> the consequences of including the class actually are or under what
> circumstances that's useful.
> 
> Reading between the lines the idea seems to be that this class is
> appropriate for recipes that build a collection of utilities each of
> which is essentially independent and is useful in its own right
> without any of the others.  Is that right?

Yes, this is correct.

> 
>>>> +    d.appendVar("PACKAGES", " " + " ".join(packages))
>>>> +    d.appendVar("PROVIDES", " " + " ".join(packages))
>>> It seems a bit strange to be putting the same things in PACKAGES and
>>> PROVIDES.  Is that actually necessary?
>> I want to be able to include procps-ps without the entire procps
>> package. I was not able to do that without the above two lines.
> What do you mean by "include procps-ps"?  It sounds like you're saying
> you want to be able to introduce procps-ps to DEPENDS, is that right?
> 

I want to be able to include a specific tool out of N number of tools
that a package builds into the image.

> p.

Re: [OE-core] [meta-oe][PATCH v4 1/3] introduce lib_subpackage

[Sinan Kaya]

On 12/5/2020 7:54 PM, Sinan Kaya wrote:
> On 12/5/2020 5:23 PM, Phil Blundell wrote:
>>> I'm open to giving it a better name. Richard pointed me to a file
>>> beginning with lib_foo.class for where this functionality could be
>>> hosted before.
>> I suppose the interesting question here, then, is "what is this class
>> actually for?"  The description above says that it "allows us to easily
>> split a recipe into subpackages" but doesn't say very much about what
>> the consequences of including the class actually are or under what
>> circumstances that's useful.
>>
>> Reading between the lines the idea seems to be that this class is
>> appropriate for recipes that build a collection of utilities each of
>> which is essentially independent and is useful in its own right
>> without any of the others.  Is that right?
> 
> Yes, this is correct.
> 
>>
>>>>> +    d.appendVar("PACKAGES", " " + " ".join(packages))
>>>>> +    d.appendVar("PROVIDES", " " + " ".join(packages))
>>>> It seems a bit strange to be putting the same things in PACKAGES and
>>>> PROVIDES.  Is that actually necessary?
>>> I want to be able to include procps-ps without the entire procps
>>> package. I was not able to do that without the above two lines.
>> What do you mean by "include procps-ps"?  It sounds like you're saying
>> you want to be able to introduce procps-ps to DEPENDS, is that right?
>>
> 
> I want to be able to include a specific tool out of N number of tools
> that a package builds into the image.
> 
>> p.
> 

Is there anything else that i need to do on this changeset to move it
forward?

I have no clue if there has been a build failure somewhere or if I have
addressed all comments.