Hi, thank you for bringing this to the list.
I have the same experience which is the reason why I haven't migrated most of my packages yet (which is not a good move because I also didn't post the problem to the list like I wanted *yet*, I only talked to people via private mail, chat or at FOSDEM about that and was working on a proposal I wanted to show next week when I am hopefully healthy again). In short: It was a very bad decision that acct-* stuff is *changing* existing stuff. This must be turned of *by default*. Maybe provide a setting a user can put into make.conf to opt into current, still new, behavior but by default, a package should never ever make changes to *existing* user (unless it knows for sure it was the only source creating that user and nothing was changed since creation which isn't easy to track). My example is a little bit different: Please think about all the systems which are managed using some kind configuration management tool (Puppet, Ansible, Salt, Chef...). It's really common and there's is nothing wrong to make use of usermod for example to alter users. All of the tools I mentioned have 'templates' (=ready to use scripts to set up common software) which will make use of things like usermod. The problem: You never expect that something in the OS will get rid of your changes and will revert to something the package manager believes should be the default. In environments where you only have to deal with Gentoo, we maybe have created something *new* which allows for new possibilities, see https://wiki.gentoo.org/wiki/OpenDKIM#The_new_way However, this is very bad: Configuration management tools are common these days. While we also have systemd which helps at least to provide some kind of interface allowing user to set timezone, time sychonization, hostname and other general settings the same way across different distribution, configuration management tools are also an abstraction layer: You write 'recipes' or 'playbooks', describe 'states' in a general language and the used cfm tool will know all the implementation details. So in the end it doesn't matter if you apply your configuration against Debian, Fedora, RHEL or Gentoo -- the system you run your code against should be in the described state after all. That's at least the idea ;-) Thanks to the new way how we manage user in Gentoo that's no longer the case: Suddenly you cannot use basic tools like usermod to make changes to users anymore because you cannot be sure that these settings won't be reverted. Also, the idea to create *packages* to represent user configuration doesn't scale. I already outlined that issue in [1]. Simple example: You have two services (SerivceA and ServiceB) both using the same package (say www-servers/nginx). We are talking about something like 'real application server'. While you can overwrite user/group via ebuild once, you can't do it multiple times for *different* roles. Especially when you have to deal with some kind of 'dynamic' stuff (see the Jenkins' discussion). Creating your own acct-* repository *per role* can't scale (aside the fact that it will be impossible to tell user, "Yeah... for Gentoo you just cannot use 'append user X to group sudo' syntax you use in your cfm tool. Instead you have to fork acct-group/sudo and put user into that ebuild and ensure that this version is installed). Also, don't forget about servers executing multiple roles at the same time: It's easier to describe something like "Make sure user X is in group Y" vs. making sure you have that single acct-* ebuild creating user X or group Y with everything you ever need right from the beginning. tl;dr We need to change current acct-* eclasses to not change things (i.e. not changing home, groups...). At least if user/group were created/modified outside of PM. See also: ========= [1] https://archives.gentoo.org/gentoo-dev/message/05c9b211eb18012d16302194a7bc37e6 -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
signature.asc
Description: OpenPGP digital signature
