| 1 |
On 1/18/20 1:10 PM, Ulrich Mueller wrote: |
| 2 |
> |
| 3 |
>> Should option (3) be viable, or do I go back to the drawing board? |
| 4 |
> |
| 5 |
> Chances are that /home is site specific, e.g. with a special backup |
| 6 |
> policy, or shared between many hosts via NFS. So IMHO /home is off |
| 7 |
> limits for the package manager. |
| 8 |
> |
| 9 |
|
| 10 |
We don't actually install anything there except the keepdir file, which |
| 11 |
is why this used to work with user.eclass. If someone later logs in as |
| 12 |
"amavis" and creates some configuration in $HOME, then that stuff is |
| 13 |
subject to your backup/sharing policy just like any other user data. |
| 14 |
|
| 15 |
I could always just use /home/amavis as $HOME and un-keepdir that |
| 16 |
location. We don't really care if the directory exists, until/unless |
| 17 |
someone logs in and starts adding configuration, so that's semantically |
| 18 |
correct. No permissions problems and no QA warnings either. |
| 19 |
|
| 20 |
But now users have to follow one more step (create /home/amavis) when |
| 21 |
setting up amavisd-new. Is the QA check really assuring a quality user |
| 22 |
experience here? |
Archives