| 1 |
On 1/19/20 2:32 PM, Alec Warner wrote: |
| 2 |
> |
| 3 |
> Earlier you wrote: |
| 4 |
> ---- |
| 5 |
> * The daemon DOES NOT need a home directory for its user. |
| 6 |
> * I DO NOT want to install anything to anyone's home directory. |
| 7 |
> * With respect to user.eclass, I'm proposing that /home be treated |
| 8 |
> EXACTLY THE SAME as it always has been. |
| 9 |
> --- |
| 10 |
> |
| 11 |
> So my question is "why not leave the homedir unset, or set it to /dev/null?" |
| 12 |
> The claim is that the daemon doesn't need a home directory, so why are |
| 13 |
> we trying to make one? |
| 14 |
> |
| 15 |
|
| 16 |
Ah, good question. As the de facto no-homedir police, even I think this |
| 17 |
case warrants an exception. Technically, the daemon's user does not need |
| 18 |
a home directory. But almost everyone that uses amavis will want to |
| 19 |
combine it with one of these programs that looks in $HOME. |
| 20 |
|
| 21 |
We could install the user with no homedir, and make the people who need |
| 22 |
it override the acct-user ebuild in an overlay, but that's a pain in the |
| 23 |
butt. Since the common case will utilize a home directory, I'd rather |
| 24 |
pick one decent location upstream, and not have 99% of users define one |
| 25 |
ad-hoc in an overlay. |
| 26 |
|
| 27 |
The reason I'm being so annoying is because it's important to get the |
| 28 |
location right. Every time the user package is reinstalled, its homedir |
| 29 |
gets reset. So it's non-trivial to override, and can't really be changed |
| 30 |
in an ebuild (usermod fails if the user is running a process). |
Archives