1 |
On Sat, 2020-01-18 at 12:51 -0500, Michael Orlitzky wrote: |
2 |
> We forbid packages from installing to /home for good reason: for most of |
3 |
> history, users (and their home directories) were outside the purview of |
4 |
> the package manager. But with GLEP81, that's changed: the package |
5 |
> manager is now in charge of creating each system user's home directory |
6 |
> and of giving it the correct permissions and ownership. |
7 |
> |
8 |
> Is the policy against installing to /home still consistent? |
9 |
> |
10 |
> For example: the mail-filter/amavisd-new daemon needs a user, typically |
11 |
> called "amavis". The daemon also needs a working directory that it can |
12 |
> write to. The obvious choice for a working directory is /var/lib/amavis, |
13 |
> but there's a catch: spamassassin, razor, pyzor, et cetera (which are |
14 |
> all used by amavis) store their configuration in the current user's home |
15 |
> directory, and not in some daemon-specific location. So "amavis" needs a |
16 |
> home directory, because that's where much of the configuration for |
17 |
> amavisd goes. |
18 |
> |
19 |
> Where do we put amavis's home directory? |
20 |
> |
21 |
> 1 /var/lib/amavis is a bad idea, because it conflicts with the working |
22 |
> directory (we don't want the two packages to get out of sync, nor do |
23 |
> we want to keep them in-sync manually). |
24 |
> |
25 |
|
26 |
Sounds like you've created an arbitrary rule that prevents the two |
27 |
packages from using the same directory, and therefore you've created |
28 |
this problem yourself. Why not just go back and reconsider using |
29 |
the same directory instead of adding complexity for ideological reasons? |
30 |
|
31 |
Is it really that problematic to have the directory created by amavisd |
32 |
user, and have all packages depend on it? |
33 |
|
34 |
-- |
35 |
Best regards, |
36 |
Michał Górny |