All of lore.kernel.org
 help / color / mirror / Atom feed
From: Darcy Watkins <dwatkins@sierrawireless.com>
To: "Burton, Ross" <ross.burton@intel.com>
Cc: yocto <yocto@yoctoproject.org>
Subject: Re: RDEPENDS and do_rootfs
Date: Thu, 31 Jan 2019 07:51:38 -0800	[thread overview]
Message-ID: <55afbacdfc53eadf173cc922acf68013e97e31d6.camel@sierrawireless.com> (raw)
In-Reply-To: <CAJTo0LYaVUuMNkxP9CyNHqWAv7RQ9xtjmAgMw_7q64BJNR3LWQ@mail.gmail.com>

Hi,

In my case, package A creates groups a1, a2 and a3.

B is actually a family of packages B1, B2 and B3 that each create user
b1, b2, or b3 respectively, but also adds the new user to groups a1, a2
and/or a3.

So in this case, it is necessary that package A first be installed AND
that its post-inst scripts have run to generate groups a1, a2 and a3.

If, as you suggest, RDEPENDS will NOT guarantee this, then I will need
to solve this another way, perhaps by...

agroups.bbclass - creates groups a1, a2 and a3 for any package recipe
that inherits it.

Package recipes, A, B1, B2 and B3 would thus all have to inherit from
agroups.bbclass.

The first package installed creates the groups in rootfs. The remaining
packages just find the groups already present.

So I think that there may be a solution for my case.

-----

I think that this limitation possibly may be related to some useradd
failures reported a few years back such as "ERROR: Tried running
useradd command 10 times without scucess, giving up". There had been
changes made by patching the shadow package and by refining the bbclass
to use file locks. I went for about three years with just the luck of
the draw that packages were installed in a good order until this showed
up. I had backported some of these changes to 'daisy' before realizing
that the groups simply hadn't been created yet.



On Thu, 2019-01-31 at 10:52 +0000, Burton, Ross wrote:
> Forgot to say, Bitbake's dependency model is loosely based on
> Debian's
> so the Debian Policy is a good read for semantics:
> 
> 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.debian.org%2Fdoc%2Fdebian-policy%2Fch-relationships.html%23binary-dependencies-depends-recommends-suggests-enhances-pre-depends&amp;data=02%7C01%7Cdwatkins%40sierrawireless.com%7Ccb4829af452948bfa95208d6876a34ed%7C08059a4c248643dd89e33a747e0dcbe8%7C1%7C0%7C636845287569900461&amp;sdata=WsJ0EjOAI7C%2BurDmAfVMCGb9SEaAWMxy%2F8Xpfks%2FjPA%3D&amp;reserved=0
> 
> Debian's "Depends" is our "RDEPENDS", what you want is "Pre-Depends"
> that we don't (yet) support.  As I said, this is just a matter of
> picking a name and then mapping it into the control file.
> 
> Ross
> 
> On Thu, 31 Jan 2019 at 10:49, Burton, Ross <ross.burton@intel.com>
> wrote:
> 
> Presumably the problem here is that you've a maintainer script
> (preinst or postinst) in B that needs a binary/library from A, and is
> failing because B's postinst is running before A is unpacked?  If
> not,
> please clarify, otherwise the problem is that DEPENDS just talks
> about
> the final solution.  If you want to express that A needs to be
> installed and configured before B is configured then you'll need to
> use Pre-Depends, which I don't believe are actually supported in the
> packaging classes yet.  I know that dpkg and opkg support this, and
> presumably rpm too, so extending the packaging classes is a few
> minutes work.
> 
> Ross
> 
> On Thu, 31 Jan 2019 at 06:51, Darcy Watkins <
> dwatkins@sierrawireless.com> wrote:
> 
> Hi,
> 
> Can someone knowledgeable with the inner workings of the build system
> please confirm...
> 
> IF package B has RDEPENDS on package A
> 
> THEN during do_rootfs task, package A will always be installed into
> rootfs first AND the post-inst scripts of package A will always be
> run
> prior to those for package B.
> 
> Also, if that can be confirmed for 'daisy' branch, that would really
> be
> helpful.  If not, then please mention as far back the branch that you
> know for sure.  Thanks!
> 
> 
> 
> --
> 
> 
> Regards,
> 
> Darcy
> 
> Darcy Watkins ::  Senior Staff Engineer, Firmware
> 
> SIERRA
> WIRELESS
> Direct  +1 604 233 7989   ::  Fax  +1 604 231 1109  ::  Main  +
> 1 604 231 1100
> 13811 Wireless Way  :: Richmond, BC Canada V6V 3A4
> [P1]
> 
> dwatkins@sierrawireless.com :: 
> https://na01.safelinks.protection.outlook.com/?url=www.sierrawireless.com&amp;data=02%7C01%7Cdwatkins%40sierrawireless.com%7Ccb4829af452948bfa95208d6876a34ed%7C08059a4c248643dd89e33a747e0dcbe8%7C1%7C0%7C636845287569900461&amp;sdata=d946J0HFRXZgDiC1QjtumL%2BX4mzpHkhlvuC1J1xEbeE%3D&amp;reserved=0
> 
> 
> 
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.yoctoproject.org%2Flistinfo%2Fyocto&amp;data=02%7C01%7Cdwatkins%40sierrawireless.com%7Ccb4829af452948bfa95208d6876a34ed%7C08059a4c248643dd89e33a747e0dcbe8%7C1%7C0%7C636845287569900461&amp;sdata=DiZmJr86q5r0i1iVk4Yraj0CB6fXY0Eczkh8HpigJlA%3D&amp;reserved=0
-- 


Regards,
 
Darcy
 
Darcy Watkins ::  Senior Staff Engineer, Firmware
 
SIERRA
WIRELESS
Direct  +1 604 233 7989   ::  Fax  +1 604 231 1109  ::  Main  +
1 604 231 1100
13811 Wireless Way  :: Richmond, BC Canada V6V 3A4
[P1]

dwatkins@sierrawireless.com :: www.sierrawireless.com





  reply	other threads:[~2019-02-01 22:26 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-30 17:15 RDEPENDS and do_rootfs Darcy Watkins
2019-01-31  7:00 ` Hopp, Denis
2019-01-31 10:49   ` Burton, Ross
2019-01-31 10:49 ` Burton, Ross
2019-01-31 10:52   ` Burton, Ross
2019-01-31 15:51     ` Darcy Watkins [this message]
2019-01-31 15:52       ` Burton, Ross

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=55afbacdfc53eadf173cc922acf68013e97e31d6.camel@sierrawireless.com \
    --to=dwatkins@sierrawireless.com \
    --cc=ross.burton@intel.com \
    --cc=yocto@yoctoproject.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.