Summary: | Update enewuser/enewgroup phase suggestions | ||
---|---|---|---|
Product: | Documentation | Reporter: | Michael Orlitzky <mjo> |
Component: | Devmanual | Assignee: | Gentoo Devmanual Team <devmanual> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | floppym |
Priority: | Normal | Keywords: | PATCH |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
update-the-wording-in-common-pkg_preinst-tasks.patch
update-pkg_preinst-pkg_setup-text-in-users_and_groups.patch |
Description
Michael Orlitzky
2014-10-19 00:51:38 UTC
Patch? :) Created attachment 390050 [details, diff]
update-the-wording-in-common-pkg_preinst-tasks.patch
Created attachment 390052 [details, diff]
update-pkg_preinst-pkg_setup-text-in-users_and_groups.patch
TWO patches! I would argue that pkg_postinst is often better than pkg_preinst. Doing it in pkg_preinst would only be necessary of some of the installed files are owned by the new user. And in that case, pkg_setup is probably better since the ownership is likely set in the src_install phase. In many cases the new user does not own any installed files, and is only referenced at runtime by things like init scripts; pkg_postinst works fine for that. (In reply to Mike Gilbert from comment #5) > I would argue that pkg_postinst is often better than pkg_preinst. I don't remember, but I probably used preinst because that's what was mentioned in bug 217042. In fact, postinst may be strictly preferable, because the new user won't be created if installation fails due to e.g. a file collision. Does anyone see a downside to postinst with respect to preinst? (In reply to Michael Orlitzky from comment #6) > (In reply to Mike Gilbert from comment #5) > > I would argue that pkg_postinst is often better than pkg_preinst. Why? > I don't remember, but I probably used preinst because that's what was > mentioned in bug 217042. In fact, postinst may be strictly preferable, > because the new user won't be created if installation fails due to e.g. a > file collision. Except that collision checks take place *before* pkg_preinst is called. > Does anyone see a downside to postinst with respect to preinst? If the ebuild needs to do any adjustments of file ownership in the image dir, then this is only possible if the owner already exists in the pkg_preinst phase. Also, the package should not be merged if user or group creation fails. (In reply to Ulrich Müller from comment #7) > > (In reply to Mike Gilbert from comment #5) > > > I would argue that pkg_postinst is often better than pkg_preinst. > > Why? Please read the rest of my comment for my arguments. I wrote three paragraphs and you only quoted the first. > > I don't remember, but I probably used preinst because that's what was > > mentioned in bug 217042. In fact, postinst may be strictly preferable, > > because the new user won't be created if installation fails due to e.g. a > > file collision. > > Except that collision checks take place *before* pkg_preinst is called. > > > Does anyone see a downside to postinst with respect to preinst? > > If the ebuild needs to do any adjustments of file ownership in the image > dir, then this is only possible if the owner already exists in the > pkg_preinst phase. The package manager only needs to do adjustments of file ownership if the ebuild installed files in src_install with some owner other than root. In this case, I would expect pkg_setup to be used for creating the user in the first place. As I previously stated, it is much more common for the new user to be used only at runtime, not at merge time. > Also, the package should not be merged if user or group creation fails. This is a valid concern. I suppose pkg_preinst is better from that perspective. (In reply to Ulrich Müller from comment #7) > > Except that collision checks take place *before* pkg_preinst is called. For a more mundane example, the user could simply hit Ctrl-C before the merge. > Also, the package should not be merged if user or group creation fails. That's a pretty good reason though. All of these issues are addressed in a much cleaner way by GLEP 81. |