On 1/4/21 9:46 AM, Thomas Deutschmann wrote:
So the main problem I see with doing this is that it becomes
impossible to reliably make changes to a user in later ebuild
revisions.
He is obviously looking for a way to allow maintainers to change users
afterwards. But if we tell people, "If you need customization, fork the
user/group ebuild in your overlay" we will disconnect these users from
future changes.
There's pretty much no reason to change a user's settings unless you've
completely fucked them up the first time around. This is precisely why
the original GLEP had mailing list reviews.
If a package depends on a user having e.g. a specific home directory so
that upgrading the package requires a corresponding revision bump of the
user, then the package is broken. I tried really hard to document this,
and to enforce it back when we had mailing list reviews. It's all in the
devmanual now.
...
When you will get LPIC certification one can expect that you have some
basic knowledge in Linux stuff allowing you to do common tasks on all
different Linux systems. Now there comes Gentoo where you aren't allowed
to use standard Linux tools like 'usermod' when deploying another
service if you don't want to risk that your service will go down when
following best practice and do regular world upgrades. Really?
You also can't use the standard linux tools to edit scripts in /usr/bin
without your changes being overwritten. This is no different... some
things need to belong to the package manager if you want package
management to work.
3) More important, the idea of forking acct-* packages whenever you need
to make modifications don't scale. Like I already outlined in February
2020, you cannot create overlays for each different user configuration:
I.e. using memcached/redis: You grant permission to socket via group. So
you put other services belonging to that application you are deploying
into your user running the key value store. Do you really expect that
one would create multiple overlays per application using one of these
services? How would you maintain hundreds of overlays? How would you
keep track that each box will use the correct overlay to get the
specific customized acct-* package? How do you deal with scenarios where
you don't just deploy single instances?
This is literally the example I gave. Our acct-user ebuilds can be added
to additional groups based on USE flags. Every server uses the same
overlay/ebuilds, but different machines get different package.use files,
pushed out by the configuration management tool.
I understand that creating an overlay with acct-user overrides will not
be for everyone, so I have no problem with adding an escape hatch. I do
think it should be off by default though, and that missing future
::gentoo changes will not be a problem unless some other error has been
committed first.
