Ah in that case there's been a lot of work since daisy to useradd etc. Ross
On Thu, 31 Jan 2019 at 15:51, Darcy Watkins <dwatk...@sierrawireless.com> wrote: > > 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&data=02%7C01%7Cdwatkins%40sierrawireless.com%7Ccb4829af452948bfa95208d6876a34ed%7C08059a4c248643dd89e33a747e0dcbe8%7C1%7C0%7C636845287569900461&sdata=WsJ0EjOAI7C%2BurDmAfVMCGb9SEaAWMxy%2F8Xpfks%2FjPA%3D&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.bur...@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 < > > dwatk...@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] > > > > dwatk...@sierrawireless.com :: > > https://na01.safelinks.protection.outlook.com/?url=www.sierrawireless.com&data=02%7C01%7Cdwatkins%40sierrawireless.com%7Ccb4829af452948bfa95208d6876a34ed%7C08059a4c248643dd89e33a747e0dcbe8%7C1%7C0%7C636845287569900461&sdata=d946J0HFRXZgDiC1QjtumL%2BX4mzpHkhlvuC1J1xEbeE%3D&reserved=0 > > > > > > > > -- > > _______________________________________________ > > yocto mailing list > > yocto@yoctoproject.org > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.yoctoproject.org%2Flistinfo%2Fyocto&data=02%7C01%7Cdwatkins%40sierrawireless.com%7Ccb4829af452948bfa95208d6876a34ed%7C08059a4c248643dd89e33a747e0dcbe8%7C1%7C0%7C636845287569900461&sdata=DiZmJr86q5r0i1iVk4Yraj0CB6fXY0Eczkh8HpigJlA%3D&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] > > dwatk...@sierrawireless.com :: www.sierrawireless.com > > > -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto