On Wednesday 13 June 2012 14:32:22 Ian Stakenvicius wrote: > On 13/06/12 02:09 PM, Fabian Groffen wrote: > > On 13-06-2012 12:00:16 -0400, Ian Stakenvicius wrote: > >> Hey all - I'd like to propose that enewuser forces updates to a > >> user's home dir and shell whenever it is called, so that if this > >> changes with new versions of an ebuild it is dealt with > >> automatically rather than having to modify them in > >> pkg_postinst/pkg_setup directly. > > > > What if some admin purposely changed home or shell for a system > > account? Would be quite annoying if every update would reset that, > > wouldn't it? > > I considered this case, and that it might be more appropriate to > duplicate 'enewuser' into a new call 'eforceuser' (or similar) which > could be used instead of 'enewuser' in cases when the currently > provided user settings should be forced. > > I decided against this as it seems also to make sense that users > created by portage should be controlled by portage.
the users only get created by portage if they don't already exist. so i
wouldn't say that the user entries in /etc/passwd "belong" to portage.
> I suppose probably the best means of handling this would be to somehow
> detect whether or not the current user settings are default and only
> apply the updates if they are; however a means of doing that (which
> would be transparent to the ebuild) is somewhat beyond my knowledge
> and abilities.
we have egetshell and egethome already. thus it's fairly easy to detect the
transition case. if they installed the older version which set values that
you now want to change:
if has_version '<foo/pkg-3' && [[ $(egetshell user) == "/bad/shell" ]] ; then
esetshell user /good/shell
fi
if has_version '<foo/pkg-3' && [[ $(egethome user) == "/old/home" ]] ; then
esethome user /new/home
fi
-mike
signature.asc
Description: This is a digitally signed message part.
