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