All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael Ho" <Michael.Ho@bmw.de>
To: <richard.purdie@linuxfoundation.org>,
	<openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [PATCH] rootfs.py: expose prepared_index and ipk_repo_workdir for OpkgPM
Date: Fri, 5 Feb 2021 14:21:52 +0000	[thread overview]
Message-ID: <6C6D328B-C39B-42E2-9AFF-60E013C57917@bmw.de> (raw)
In-Reply-To: <2148a893a9deec135bfa733be2a4ec6c99e9201e.camel@linuxfoundation.org>

Hi RP,

Thanks for the comments. Sounds good to me. I'll send another patchset.

I'll see if I can also set up a renaming patch for the other IPKG variables for
review comments.

Kind regards,
Michael

-- 
BMW Car IT GmbH
Michael Ho
Spezialist Entwicklung – Build and Release Engineering
Lise-Meitner-Straße 14
89081 Ulm

Tel.: ­+49-731-37804-071
Mobil: +49-152-54980-471
Fax: +49-731-37804-001
Mail: michael.ho@bmw-carit.de 
Web: http://www.bmw-carit.de <http://www.bmw-carit.de/>
-------------------------------------------------------------------------
BMW Car IT GmbH
Geschäftsführer: Kai-Uwe Balszuweit und Michael Böttrich
Sitz und Registergericht: München HRB 134810
-------------------------------------------------------------------------
 

On 05.02.21, 13:33, "Richard Purdie" <richard.purdie@linuxfoundation.org> wrote:

    On Fri, 2021-02-05 at 09:51 +0100, Michael Ho wrote:
    > From: Michael Ho <Michael.Ho@bmw.de>
    > 
    > The OpkgPM class has several constructor options that allows for skipping
    > the ipk repository set up and controlling the ipk repository directory. This
    > commit exposes these option via the OpkgRootfs class so others can make use
    > of them if they wish to.
    > 
    > Adds the bitbake variables "IPKGREPO_TARGET_PREPARED" and "IPKGREPO_TARGET"
    > to act as the interfaces.
    > 
    > Signed-off-by: Michael Ho <Michael.Ho@bmw.de>
    > ---
    >  meta/lib/oe/package_manager/ipk/rootfs.py | 14 ++++++++++++--
    >  1 file changed, 12 insertions(+), 2 deletions(-)
    > 
    > diff --git a/meta/lib/oe/package_manager/ipk/rootfs.py b/meta/lib/oe/package_manager/ipk/rootfs.py
    > index 26dbee6..6313b72 100644
    > --- a/meta/lib/oe/package_manager/ipk/rootfs.py
    > +++ b/meta/lib/oe/package_manager/ipk/rootfs.py
    > @@ -129,6 +129,14 @@ class PkgRootfs(DpkgOpkgRootfs):
    >          self.manifest = PkgManifest(d, manifest_dir)
    >          self.opkg_conf = self.d.getVar("IPKGCONF_TARGET")
    >          self.pkg_archs = self.d.getVar("ALL_MULTILIB_PACKAGE_ARCHS")
    > +        self.opkg_repo = self.d.getVar("IPKGREPO_TARGET")
    > +        self.opkg_repo_prepared = self.d.getVar("IPKGREPO_TARGET_PREPARED")
    > +
    > +        kwargs = {}
    > +        if self.opkg_repo:
    > +            kwargs["ipk_repo_workdir"] = self.opkg_repo
    > +        if self.opkg_repo_prepared:
    > +            kwargs["prepare_index"] = False
    >  
    > 

    It seems reasonable to expose them, I'd just suggest that we don't put
    them in self here but do something like:

    +        if self.d.getVar("IPKGREPO_TARGET"):
    +            kwargs["ipk_repo_workdir"] = self.opkg_repo
    +        if self.d.getVar("IPKGREPO_TARGET_PREPARED"):
    +            kwargs["prepare_index"] = False

    and my only other concern is the naming. Somehow we need to get from
    the mess we're currently in to some kind of more consistent and
    understandable naming of variables.

    OPKG_ROOTFS_FEED_WORKDIR
    OPKG_ROOTFS_REBUILDINDEX

    maybe?

    I'd also yes, we should document them.

    Cheers,

    Richard


      reply	other threads:[~2021-02-05 14:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-05  8:51 [PATCH] RFC: rootfs.py: expose prepared_index and ipk_repo_workdir for OpkgPM Michael Ho
2021-02-05  8:51 ` [PATCH] " Michael Ho
2021-02-05 12:33   ` [OE-core] " Richard Purdie
2021-02-05 14:21     ` Michael Ho [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=6C6D328B-C39B-42E2-9AFF-60E013C57917@bmw.de \
    --to=michael.ho@bmw.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.