From: Ioan-Adrian Ratiu <adrian.ratiu@ni.com>
To: Khem Raj <raj.khem@gmail.com>, openembedded-core@lists.openembedded.org
Subject: Re: [] default-providers: introduce VIRTUAL-RUNTIME_initscripts
Date: Fri, 13 Jul 2018 15:45:59 +0300 [thread overview]
Message-ID: <87zhyvxq0o.fsf@ni.com> (raw)
In-Reply-To: <918da0cc-b3f8-b34c-91cb-7a8c0e550741@gmail.com>
On Fri, 13 Jul 2018, Khem Raj <raj.khem@gmail.com> wrote:
> On 7/13/18 3:22 AM, Ioan-Adrian Ratiu wrote:
>> On Thu, 12 Jul 2018, Khem Raj <raj.khem@gmail.com> wrote:
>>> On 7/10/18 7:44 AM, Ioan-Adrian Ratiu wrote:
>>>> Commits 1202307b24 ("lsbinitscripts: don't use update-alternatives")
>>>> cdcebd81c87 ("initscripts: don't use update-alternatives") and
>>>> 061fa614cec ("update-alternatives.bbclass: refuse to manage SysV init
>>>> scripts") make sure that the lsbinitscripts and initscripts packages
>>>> conflict with eachother and can't be alternatives.
>>>>
>>>> lsb has a hardcoded dependency on lsbinitscripts which makes it
>>>> impossible to install on systems using initscripts (acl depends on
>>>> initscripts) and lsbinitscripts also has a runtime dependency on the
>>>> full util-linux package making it an unwanted dependency on busybox
>>>> systems.
>>>>
>>>> Therefore introduce VIRTUAL-RUNTIME_initscripts to choose between the
>>>> versions of /etc/init.d/functions and allow installing lsb alongside
>>>> initscripts avoiding the full util-linux dependency.
>>>>
>>>> Default it to lsbinitscripts so we don't have a change in the existing
>>>> behavior; distros/users can override it in their conf when needed.
>>>>
>>>
>>> We already have PREFERRED_RPROVIDER_initd-functions I wonder if that is
>>> the right option to use here.
>>
>> (I've sent patch v2 which fixes a build-error causing typo, sorry for it :)
>>
>> We could use PREFERRED_RPROVIDER_initd-functions but that currently
>> defaults to "initscripts". In all my layers nothing is using that
>> variable, so would it be ok to change its default to lsbinitscripts to
>> preserve the current default lsb/util-linux behaviour?
>>
>> Or are you ok with using it as is, leaving the default to "initscripts"
>> and just change the lsb dependency?
>>
>
> if it is unused then change it to lsbscripts.
>
Ok, thanks. Please discard these VIRTUAL-RUNTIME_initscripts patches.
>>>
>>>> Signed-off-by: Ioan-Adrian Ratiu <adrian.ratiu@ni.com>
>>>> ---
>>>> meta/conf/distro/include/default-providers.inc | 1 +
>>>> meta/recipes-extended/lsb/lsb_5.0.bb | 3 +--
>>>> meta/recipes-extended/packagegroups/packagegroup-core-lsb.bb | 2 +-
>>>> 3 files changed, 3 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/meta/conf/distro/include/default-providers.inc b/meta/conf/distro/include/default-providers.inc
>>>> index e65c1ed323..37e7478ea0 100644
>>>> --- a/meta/conf/distro/include/default-providers.inc
>>>> +++ b/meta/conf/distro/include/default-providers.inc
>>>> @@ -23,6 +23,7 @@ VIRTUAL-RUNTIME_update-alternatives ?= "update-alternatives-opkg"
>>>> VIRTUAL-RUNTIME_apm ?= "apm"
>>>> VIRTUAL-RUNTIME_alsa-state ?= "alsa-state"
>>>> VIRTUAL-RUNTIME_getopt ?= "util-linux-getopt"
>>>> +VIRTUAL-RUNTIME_initscripts ?= "lsbinitscripts"
>>>> VIRTUAL-RUNTIME_wireless-tools ?= "iw wireless-tools"
>>>> VIRTUAL-RUNTIME_base-utils ?= "busybox"
>>>> VIRTUAL-RUNTIME_base-utils-hwclock ?= "busybox-hwclock"
>>>> diff --git a/meta/recipes-extended/lsb/lsb_5.0.bb b/meta/recipes-extended/lsb/lsb_5.0.bb
>>>> index df4812e4bc..6cb1751664 100644
>>>> --- a/meta/recipes-extended/lsb/lsb_5.0.bb
>>>> +++ b/meta/recipes-extended/lsb/lsb_5.0.bb
>>>> @@ -8,8 +8,7 @@ LSB_CORE_x86 = "lsb-core-ia32"
>>>> LSB_CORE_x86-64 = "lsb-core-amd64"
>>>> RPROVIDES_${PN} += "${LSB_CORE}"
>>>>
>>>> -# lsb_release needs getopt, lsbinitscripts
>>>> -RDEPENDS_${PN} += "${VIRTUAL-RUNTIME_getopt} lsbinitscripts"
>>>> +RDEPENDS_${PN} += "${VIRTUAL-RUNTIME_getopt} ${VIRTUAL-RUNTIME_initscripts}"
>>>>
>>>> LIC_FILES_CHKSUM = "file://README;md5=12da544b1a3a5a1795a21160b49471cf"
>>>>
>>>> diff --git a/meta/recipes-extended/packagegroups/packagegroup-core-lsb.bb b/meta/recipes-extended/packagegroups/packagegroup-core-lsb.bb
>>>> index 53d100ce74..74547b0773 100644
>>>> --- a/meta/recipes-extended/packagegroups/packagegroup-core-lsb.bb
>>>> +++ b/meta/recipes-extended/packagegroups/packagegroup-core-lsb.bb
>>>> @@ -118,7 +118,7 @@ RDEPENDS_packagegroup-core-lsb-misc = "\
>>>> gettext \
>>>> gettext-runtime \
>>>> groff \
>>>> - lsbinitscripts \
>>>> + ${VIRTUAL_RUNTIME-initscripts} \
>>>> lsbtest \
>>>> lsof \
>>>> strace \
>>>>
prev parent reply other threads:[~2018-07-13 13:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-10 13:44 [] default-providers: introduce VIRTUAL-RUNTIME_initscripts Ioan-Adrian Ratiu
2018-07-12 16:04 ` Khem Raj
2018-07-13 9:22 ` Ioan-Adrian Ratiu
2018-07-13 12:30 ` Khem Raj
2018-07-13 12:45 ` Ioan-Adrian Ratiu [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=87zhyvxq0o.fsf@ni.com \
--to=adrian.ratiu@ni.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=raj.khem@gmail.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