| 1 |
On 8/23/19 3:45 PM, Michał Górny wrote: |
| 2 |
>> |
| 3 |
>> That used to be acceptable, since the "enewuser" command with the home |
| 4 |
>> directory was part of the package that used that directory. But now that |
| 5 |
>> the user data are in another package, we can't depend on them reliably. |
| 6 |
>> |
| 7 |
> |
| 8 |
> ...and why is that, exactly? Are you assuming that someone will take |
| 9 |
> over the dedicated user for another purpose and change its home |
| 10 |
> directory? |
| 11 |
> |
| 12 |
|
| 13 |
The fact that the home directory can change is a feature that you |
| 14 |
yourself went out of the way to support. We can't rely on the value of |
| 15 |
ACCT_USER_HOME in a dependency, and nothing is gained by doing so -- so |
| 16 |
why do it? That's one reason. |
| 17 |
|
| 18 |
It also greatly simplifies the guidelines. Have you ever refactored |
| 19 |
something and had it just feel right? This just feels right. I think |
| 20 |
most developers don't care about these details and would just like to |
| 21 |
get the job done. If we can give them a list of a few simple guidelines |
| 22 |
to follow, then everyone's happy. |
| 23 |
|
| 24 |
If we put the keepdir/fowners/fperms in the logically-correct place, it |
| 25 |
allows us to also say: don't use a home directory owned by another |
| 26 |
package (use the default). That in turn prevents acct-user packages from |
| 27 |
clobbering the permissions and ownership on stuff that belongs to |
| 28 |
somebody else. All pros, no cons. |
Archives