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