[OE-core] [PATCHv2 1/1] Revert "useradd.bbclass: remove user/group created by the package in clean* task"
Peter Kjellerstedt
peter.kjellerstedt at axis.com
Tue Apr 12 17:28:17 UTC 2016
> -----Original Message-----
> From: Otavio Salvador [mailto:otavio.salvador at ossystems.com.br]
> Sent: den 12 april 2016 18:36
> To: Richard Purdie
> Cc: Peter Kjellerstedt; Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCHv2 1/1] Revert "useradd.bbclass: remove
> user/group created by the package in clean* task"
>
> On Tue, Apr 12, 2016 at 11:54 AM, Richard Purdie
> <richard.purdie at linuxfoundation.org> wrote:
> > On Tue, 2016-04-12 at 15:18 +0200, Peter Kjellerstedt wrote:
> >> Removal of users/group when cleansstating a recipe as implemented here
> >> totally breaks when multiple recipes install the same user/groups.
> >>
> >> This reverts commit b5304ce438666a7418746f4ddd32703ae3188089.
> >>
> >> Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt at axis.com>
> >> ---
> >> meta/classes/sstate.bbclass | 5 -----
> >> meta/classes/useradd.bbclass | 29 -----------------------------
> >> 2 files changed, 34 deletions(-)
> >
> > This is one of these situations where we can't win.
> >
> > Without this code, there is no way to clean up these users out the
> > sysroot. Having to tell people to "wipe TMPDIR" when the parameters
> > used to create a user change for example is rather bad. It also has bad
> > implications for build determinism and the expectation that a "clean"
> > undoes the changes a recipe makes.
Well, build determinism is also broken when it comes to creating
users and groups if two recipes tries to create the same user (or
group) with different definitions, since the first recipe that
happens to be installed wins...
In our case we have solved this by using the useradd-staticids.bbclass,
which allows us to have common definitions for the users, in addition
to only use GROUPMEMS_PARAM to add users to groups. But there should
really be some QA warning/error to catch this from happening...
> > Have we ever documented we support the same user being created by
> > multiple recipes?
I am pretty sure you have not documented that it is NOT supported...
Because if it was not supported, then I would have expected errors
if two recipes tried to install the same user/group. And I cannot
see the logic behind not allowing it (except because it makes it
hard to uninstall users and groups), because if a package needs a
user/group, then of course it should be allowed to make sure the
user/group exists...
> > I'm open to proposals about how to fix this but an outright revert
> > doesn't seem like the right thing to do. Making it optional so you can
> > disable it for your multiple recipes case would perhaps be a better
> > option for example.
Making it a configuration option does not sound like a good idea
because having multiple recipes install the same user/group can lead
to build errors and that is not something you should need to configure
around.
One way to solve the problem of both creating users/groups and being
able to remove them in deterministic ways would be to only allow them
to be created from special user/group recipes. Then the normal
dependency handling would make sure they are installed and removed as
needed. The drawback of course would be all the extra packages needed
to create users and groups (which in our case would be a considerable
number of packages).
An alternative solution would be to create package specific files
somewhere in the sysroot which keep track of what users and groups a
particular package has created, i.e., something like
"users/systemd-timesync/systemd" which would be created by the systemd
package when it creates the systemd-timesync user. That way it would
be easy to only remove the systemd-timesync user when
"users/systemd-timesync" is empty. A benefit of this solution is that
it would only require changes to useradd.bbclass so it can be
implemented without having to change any recipes. A minor drawback is
that it would not solve the problem of different recipes creating the
same user differently.
> I am not against the change by the timing; it should be merged in
> master as soon it is open for 2.2 work.
I have to agree with this. Above are two solutions on how to make
this work, but doing it at this stage of the release schedule is
probably asking a bit much (especially the first solution)...
//Peter
More information about the Openembedded-core
mailing list