| 1 |
On 5/29/19 5:50 AM, Jaco Kroon wrote: |
| 2 |
>> |
| 3 |
>> This GLEP follows the best practice of leaving obsolete user/groups |
| 4 |
>> accounts intact. This guarantees that no files with stale ownership are |
| 5 |
>> left (e.g. on unmounted filesystems) and that the same UID/GID is not |
| 6 |
>> reused for another user/group. |
| 7 |
> |
| 8 |
> The type of checks for both this and certain updates contemplated above |
| 9 |
> are similar. And expensive (resources) as you rightly say. I would |
| 10 |
> provide the tools to perform these checks but in the ebuild I'd rather |
| 11 |
> the checks be done asap (pkg_pretend?). If we can fail there and |
| 12 |
> stating what the admin should do to rectify the issue that would be the |
| 13 |
> best solution in my personal opinion. Ie, from the package manager I'd |
| 14 |
> state how, but not actually action these changes. |
| 15 |
> |
| 16 |
|
| 17 |
My original goal here was to have "emerge -C <user>" actually uninstall |
| 18 |
the user. That turns out to be highly unwise, because you need to audit |
| 19 |
the system for things owned and used by said user, and to clean them all |
| 20 |
up beforehand. That can take forever, and can't be automated. |
| 21 |
|
| 22 |
Plan (b) was to do exactly as you asked: have the uninstall process bail |
| 23 |
out, and tell you what to do. That's... also technically infeasible, |
| 24 |
because we don't have a way to make an ebuild bail out of an uninstall. |
| 25 |
This could change in the future with an EAPI/PMS update, but simply |
| 26 |
isn't an option right now. |
Archives