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