On Fri, 2014-12-12 at 10:09 +0100, José Bollo wrote: > Le vendredi 12 décembre 2014 à 09:27 +0100, Patrick Ohly a écrit : > > On Thu, 2014-11-27 at 11:28 +0100, José Bollo wrote: > > > Le jeudi 27 novembre 2014 à 10:23 +0100, Patrick Ohly a écrit : > > > > Hello! > > > > > > > > It hasn't become clear to me in the gumd and image creation discussions > > > > whether .rpm postin/un scripts can still depend on useradd and userdel > > > > to create users for system services (example: avahi daemon runs as user > > > > "avahi") dynamically. > > > > > > > > If so, what are the right runtime dependencies (if any) to ensure that > > > > the commands are really available? > > > > > > > > If not, then I guess we maintain a static configuration of such daemons > > > > and never modify it during package install/uninstall? Again, avahi is a > > > > good example, because that's what's currently done for the "avahi" user > > > > (see > > > > https://review.tizen.org/gerrit/#/admin/projects/platform/upstream/setup). > > > > > > > > > > Hi Patrick, > > > > > > That is a real problem. I advocated on this list to have gumd providing > > > a legacy scripts: useradd.... We will switch to gumd very soon (see > > > https://review.tizen.org/gerrit/#/c/30885/ ). > > > > That was merged. But it doesn't remove anything, so do we still have the > > useradd/remove commands and are allowed to use them? > > > > Hello Patrick, > > Yes we put in images all these novelties! And are planning to light it > on asap. > > So yes gumd is in the image. > > As you know I was advocating for having in gumd wrappers for the old > useradd/groupadd/userdel/groupdel commands. > > But frankly, I had no real feedback on this proposal and I was not > expecting to have to do it. > > I know from Kevin and Ronan that you are facing issues about user > creation in yocto but dont understand much what it is exactly. More > explaination would help.
It's the same issue that all developers face at the moment: is it okay to put calls to [user|group]/[add|del] into .spec files? And if yes, do we need an explicit runtime dependency to ensure that the commands are actually available? Dependency on what? > I put at the end of this mail the result of the commands "rpm -ql gumd" > and "rpm -ql pwdutils" that are showing the content of the to projects. So it looks like pwdutils is still available and providing the commands. A hard dependency on it probably can be avoided in spec files by depending on the commands and not the package. > From my (not very clear) understanding, in tizen/common/obs the project > platform/upstream/setup is included but not in tizen-yocto project. > Well, why not. For consistency tizen-yocto should also use it. It probably just hasn't been done yet. Just guessing, though, Kevin and Ronan are the ones who know. > But to be more compliant to yocto it seems that it is not what have to > be done. Yocto doesn't impose it's own policy. A distro built with Yocto can make its own choices. The problem is the lack of a clear policy (and implementation) in Tizen. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
