public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Michael Orlitzky <mjo@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] GLEP81 and /home
Date: Sat, 18 Jan 2020 12:51:50 -0500	[thread overview]
Message-ID: <825bd707-faa2-f956-edbb-a11a8d82296b@gentoo.org> (raw)

We forbid packages from installing to /home for good reason: for most of
history, users (and their home directories) were outside the purview of
the package manager. But with GLEP81, that's changed: the package
manager is now in charge of creating each system user's home directory
and of giving it the correct permissions and ownership.

Is the policy against installing to /home still consistent?

For example: the mail-filter/amavisd-new daemon needs a user, typically
called "amavis". The daemon also needs a working directory that it can
write to. The obvious choice for a working directory is /var/lib/amavis,
but there's a catch: spamassassin, razor, pyzor, et cetera (which are
all used by amavis) store their configuration in the current user's home
directory, and not in some daemon-specific location. So "amavis" needs a
home directory, because that's where much of the configuration for
amavisd goes.

Where do we put amavis's home directory?

  1 /var/lib/amavis is a bad idea, because it conflicts with the working
    directory (we don't want the two packages to get out of sync, nor do
    we want to keep them in-sync manually).

  2 /var/lib/amavis/home was my next choice, because logically it puts
    the amavisd configuration in a subdirectory of the place where all
    of the other amavis stuff goes, and because it doesn't have the
    same issue that (1) does.

    But there's a problem: if we create /var/lib/amavis/home before
    amavisd-new is installed (as happens when you emerge amavisd-new),
    then /var/lib/amavis winds up root:root and the installation of
    amavisd-new doesn't change that. So now amavisd-new doesn't work,
    because it can't write to its working directory.

    This is a combination of an implementation detail and the fact that
    the PMS doesn't cover directories; but ultimately, it just doesn't
    work reliably.

  3 /home/amavis also seems fine to me, except for the fact that it's a
    QA violation to install there.

Note that we could always set system users' home directories to
/home/whatever. It has only become a QA violation with GLEP81 because
the eclass calls keepdir on the user's home directory.

Should option (3) be viable, or do I go back to the drawing board?


             reply	other threads:[~2020-01-18 17:52 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-18 17:51 Michael Orlitzky [this message]
2020-01-18 18:10 ` [gentoo-dev] GLEP81 and /home Ulrich Mueller
2020-01-18 23:38   ` Michael Orlitzky
2020-01-19  0:21     ` Rich Freeman
2020-01-19  2:50       ` Michael Orlitzky
2020-01-19 11:29         ` Rich Freeman
2020-01-19 15:49           ` Michael Orlitzky
2020-01-19 17:42             ` Rich Freeman
2020-01-19 18:37               ` Michael Orlitzky
2020-01-19 19:02                 ` Rich Freeman
2020-01-19 19:27                   ` Michael Orlitzky
2020-01-19 19:47                     ` Rich Freeman
2020-01-19 21:00                       ` Michael Orlitzky
2020-01-19 22:09                         ` Michael Orlitzky
2020-01-20  1:20                         ` Rich Freeman
2020-01-20  1:51                           ` Michael Orlitzky
2020-01-20  2:52                             ` Rich Freeman
2020-01-20  3:16                               ` Michael Orlitzky
2020-01-20  3:40                                 ` Rich Freeman
2020-01-20  3:57                                   ` Michael Orlitzky
2020-01-19 19:37             ` Robin H. Johnson
2020-01-19 19:19         ` Alec Warner
2020-01-19 19:28           ` Michael Orlitzky
2020-01-19 19:32             ` Alec Warner
2020-01-19 20:44               ` Michael Orlitzky
2020-01-18 19:03 ` Alec Warner
2020-01-18 20:16   ` Michael Orlitzky
2020-01-18 19:08 ` Michał Górny
2020-01-18 19:44   ` Michael Orlitzky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=825bd707-faa2-f956-edbb-a11a8d82296b@gentoo.org \
    --to=mjo@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox