public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: Gylstorff Quirin <quirin.gylstorff@siemens.com>
To: Henning Schild <henning.schild@siemens.com>,
	"T. Schaffner" <tobias.schaffner@siemens.com>
Cc: isar-users@googlegroups.com, michael.adler@siemens.com
Subject: Re: [PATCH 0/5] allow creation of users/groups before rootfs creation
Date: Wed, 25 Jan 2023 14:44:40 +0100	[thread overview]
Message-ID: <b026d2e3-98eb-f20b-606d-22d38b259852@siemens.com> (raw)
In-Reply-To: <20230125142901.597613d7@md1za8fc.ad001.siemens.net>



On 1/25/23 14:29, Henning Schild wrote:
> Am Wed, 25 Jan 2023 10:01:51 +0100
> schrieb "T. Schaffner" <tobias.schaffner@siemens.com>:
> 
>> From: Tobias Schaffner <tobias.schaffner@siemens.com>
>>
>> This patch series will allow to specify a `pre` flag for the USER_ and
>> GROUP_ bitbake variables. If this flag is set to `true` the given user
>> or group will be created in the rootfs configuration step instead of
>> on rootfs postprocessing. This is helpful when a specific id should
>> be used which would otherwise be picked by a user or group created by
>> one of the installed packages.
> 
> While i do understand the reason i am not sure how relevant that is.
> Why would anything only function with a fixed ID? Whoever provided that
> thing should maybe fix it.

Specific IDs are necessary for Updating an A/B rootfs system with a 
persistent partition. In this case you do not want to change any IDs as
this can lead to wrong file permissions.
> 
> So i am willing to say that this is super-niche! And it deserves a
> niche-solution in its layer, not a feature in Isar.
> 
> You could hook in a task between bootstrap and image_install. Or you
> could rebuild a bootstrap package to have reserved ids. You could run
> "the thing" in namespaces ...
> 
> So is that really relevant? Please go into detail.
> 
> Whatever happens i think the python rewrite is cool. But the code may
> have been coming/inspired from OE ... in which case it would not be
> cool, because it would fork away further.


OE uses a complete different implementation than to original:
https://git.openembedded.org/openembedded-core/tree/meta/classes/useradd.bbclass

see also:

https://git.openembedded.org/openembedded-core/tree/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb 



Quirin
> 
> Henning
> 
>> A rewrite of the image-account-extension in python was done on the
>> way. This allows us to drop a lot of encoding and parsing code that
>> was used to transition to shell and therefore made it easier to read
>> and maintain.
>>
>> Using python functions for more complex tasks allows us the usage of
>> unittests. A very basic infrastructure for unittesting using the build
>> in python unittest and the bb.parse module was added. This was used to
>> test the re-implementation of the image-account-extension as a first
>> showcase.
>>
>> Tobias Schaffner (5):
>>    simplify image-account-extension
>>    allow creation of users/groups before rootfs creation
>>    create a minimal python unittest infrastructure
>>    add unittests for the image-account-extension
>>    set minimal python version in user_manual to 3.5
>>
>>   doc/user_manual.md                            |   4 +-
>>   meta/classes/image-account-extension.bbclass  | 391
>> +++++++----------- testsuite/unittests/README.md                 |
>> 28 ++ testsuite/unittests/bitbake.py                |  37 ++
>>   testsuite/unittests/rootfs.py                 |  45 ++
>>   .../unittests/test_image_account_extension.py | 175 ++++++++
>>   6 files changed, 434 insertions(+), 246 deletions(-)
>>   create mode 100644 testsuite/unittests/README.md
>>   create mode 100644 testsuite/unittests/bitbake.py
>>   create mode 100644 testsuite/unittests/rootfs.py
>>   create mode 100644
>> testsuite/unittests/test_image_account_extension.py
>>
> 





  reply	other threads:[~2023-01-25 13:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-25  9:01 T. Schaffner
2023-01-25  9:01 ` [PATCH 1/5] simplify image-account-extension T. Schaffner
2023-01-25  9:01 ` [PATCH 2/5] allow creation of users/groups before rootfs creation T. Schaffner
2023-01-25  9:01 ` [PATCH 3/5] create a minimal python unittest infrastructure T. Schaffner
2023-01-25  9:01 ` [PATCH 4/5] add unittests for the image-account-extension T. Schaffner
2023-01-25  9:01 ` [PATCH 5/5] set minimal python version in user_manual to 3.5 T. Schaffner
2023-01-25 13:29 ` [PATCH 0/5] allow creation of users/groups before rootfs creation Henning Schild
2023-01-25 13:44   ` Gylstorff Quirin [this message]
2023-01-25 16:29     ` Henning Schild
2023-01-25 20:55       ` Schaffner, Tobias
2023-01-25 21:38         ` Henning Schild
2023-01-26  8:21           ` Schaffner, Tobias
2023-01-26  8:48             ` Florian Bezdeka
2023-01-26 10:27               ` Henning Schild
2023-01-26  9:59             ` Henning Schild

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=b026d2e3-98eb-f20b-606d-22d38b259852@siemens.com \
    --to=quirin.gylstorff@siemens.com \
    --cc=henning.schild@siemens.com \
    --cc=isar-users@googlegroups.com \
    --cc=michael.adler@siemens.com \
    --cc=tobias.schaffner@siemens.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