Improvements for useradd-staticids.bbclass

It is now 1.5 months since I originally supplied these patches. The only comment I received was about a couple of unnecessary spaces that I had removed. After explaining why removing them should not make any change to the implementation (more than a month ago), I have not received any response at all even after pushing for it on the list (a month ago) and in private (two weeks ago).

Since I am now fed up with waithing for any response, I have taken the time to split out the removal of those three spaces into a separate patch in the vain hope that this will make the patches suitable to be applied...

Now I will go on vacation till the beginning of the next year, hoping that the patches have been applied when I get back. So until then, Merry Christmas and a Happy New Year!

Original patch set description below.

This series of patches aims to improve useradd-staticids.bbclass.

We are currently using useradd-staticids.bbclass to make sure all users and groups have well defined IDs. So far we have had the definitions of the users both in the recipes and in the passwd file used by useradd-staticids.bbclass. Since we have a huge number of recipes that create users, having to duplicate the definitions all over the place has turned out to be a burden we should be able to avoid.

So the current plan for us is to have one passwd file per layer with the definitions of all users that layer needs. These definitions do not include the static IDs for the users. Instead the static IDs for the users are specified in a distro specific passwd-static file. There is also a distro specific group-static file for the group IDs. With that in place it should be enough to define a user as:

USERADD_PARAM_${PN} = "--system foobar"

in a recipe and let useradd-staticids.bbclass handle the specifics for how that user should be defined.

The above worked fine for all users that had a primary group with the same name as the user. However, it turned out that for users that wanted some other primary group, specifying it in the passwd file was not enough. We still had to add --gid <some group> in the recipe where <some group> had to match what was specified in the passwd file. This was less than optimal, and somewhat defeated the setup.

It also turned out that for users with a primary group that does not match the user name, useradd-staticids.bbclass would still add the creation of a group with the same name as the user (when it parsed the passwd-static file) and the add another creation of the correct group (when it parsed the passwd file).

So after spending quite a lot of time on trying to decode how rewrite_useradd() calculated the --gid option, I came up with this series of changes that should correct the problems described above and make the code easier to understand while (hopefully) maintaining compatibility with the old code.

//Peter

The following changes since commit 5f406915b5e26761faa4ea5e0edd887ac5ae6e2f:

bitbake: toaster: remove 2 confusing parameters (2015-12-18 13:51:54 +0000)

are available in the git repository at:

git://git.yoctoproject.org/poky-contrib pkj/useradd_improvements
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=pkj/useradd_improvements

Peter Kjellerstedt (6):
useradd-staticids.bbclass: Treat mutually exclusive options as such useradd-staticids.bbclass: Make --no-user-group have effect useradd-staticids.bbclass: Simplify some logic useradd-staticids.bbclass: Simplify the logic for when to add groups useradd-staticids.bbclass: Read passwd/group files before parsing useradd-staticids.bbclass: Remove unnecessary spaces

 meta/classes/useradd-staticids.bbclass | 192 ++++++++++++++++++---------------
 1 file changed, 103 insertions(+), 89 deletions(-)

2.1.0