On 5/29/19 5:50 AM, Jaco Kroon wrote:
>>
>> This GLEP follows the best practice of leaving obsolete user/groups
>> accounts intact.  This guarantees that no files with stale ownership are
>> left (e.g. on unmounted filesystems) and that the same UID/GID is not
>> reused for another user/group.
> 
> The type of checks for both this and certain updates contemplated above 
> are similar.  And expensive (resources) as you rightly say. I would 
> provide the tools to perform these checks but in the ebuild I'd rather 
> the checks be done asap (pkg_pretend?).  If we can fail there and 
> stating what the admin should do to rectify the issue that would be the 
> best solution in my personal opinion.  Ie, from the package manager I'd 
> state how, but not actually action these changes.
> 

My original goal here was to have "emerge -C <user>" actually uninstall
the user. That turns out to be highly unwise, because you need to audit
the system for things owned and used by said user, and to clean them all
up beforehand. That can take forever, and can't be automated.

Plan (b) was to do exactly as you asked: have the uninstall process bail
out, and tell you what to do. That's... also technically infeasible,
because we don't have a way to make an ebuild bail out of an uninstall.
This could change in the future with an EAPI/PMS update, but simply
isn't an option right now.

Reply via email to