On 9/2/19 12:32 PM, Mike Gilbert wrote: > > I can't really agree with the advice given in this section. > > If I'm maintaining a package and an associated acct-user package, I'm > going to keep the two in sync. I don't see why I should have to create > a directory via pkg_postinst when I could allow the acct-user package > to do it for me. > > That the data is "non-local" is irrelevant if I'm maintaining both ebuilds. >
We already have similar policies for other sorts of dependencies. If your package links to libfoo, then libfoo goes in RDEPEND even if it would be pulled in by some other dependency that you maintain. Developers retire and packages change hands all the time -- having an implicit dependency is asking for trouble, especially considering that the explicit approach isn't much more onerous: it's one extra line. To the next guy, the dependency won't be implicit, it will be nonexistent. Whether you find this reasoning persuasive or not, there is at least some precedent for it. In the acct-user case, both methods will result in the directory being keepdir'd. But ultimately, the point I'm trying to make in the patch is that one method will always work while the other might not if something outside of your control changes. Neither is more difficult, so why not choose the way that always works, and set up the directory in the ebuild that uses it? User packages can be shared and home directories can change by the design of GLEP81. You can't guarantee that no one else is going to depend on your acct-user package, or that its home directory will never have to change, or that you will maintain both of them forever. In any of those situations, having the directory creation be a side effect of enewuser is a bad idea. Why should my package create your package's localstatedir just because I want to share a username? And why should I have to violate the principle of least privilege, giving my user a home directory it doesn't need? Yeah, we could address those problems when they arise; but if they can be avoided entirely by an extra call or two to fowners/fperms, I think it's worth doing so. Or at least worth *suggesting* that we do so. If any of this is more persuasive than the original, I can update the patch. If not, I can, uh, try harder.