I don't think removing entries without checking how long they have been unused is a good idea,

If you mark an entry as free, it means it can be used again, which will most probably lead to conflicts or double entries in /etc/passwd or /etc/groups.

We don't seem to be running out of free uids and gids, a quick grep tells me we have more than 300 free in each.

I don't think removing entries without checking how long they have been unused is a good idea,

And how long an entry should be unused to make viable for deletion? I doubt we have a policy for that.

If you mark an entry as free, it means it can be used again, which will most probably lead to conflicts or double entries in /etc/passwd or /etc/groups.

I checked how users/groups are created in there is indeed no check for both name and UGID.
I think the solution here would be to check both name and UGID and fail package's installation if the user/group with specified UID exists, but names do not match.
Then let the administrator clean up old entries.

We don't seem to be running out of free uids and gids, a quick grep tells me we have more than 300 free in each.

We'll have to do this sooner or later and here I am to do that. Why wait for free entries to exhaust?

In D56578#1295345, @arrowd wrote:

I don't think removing entries without checking how long they have been unused is a good idea,

And how long an entry should be unused to make viable for deletion? I doubt we have a policy for that.

I'd say at least 10-15 years before an entry can be recycled.

We don't seem to be running out of free uids and gids, a quick grep tells me we have more than 300 free in each.

We'll have to do this sooner or later and here I am to do that. Why wait for free entries to exhaust?

I'm not convinced this solves a real problem.
I don't see this coming up as a problem in practice.
Given the existing backlog of actual framework and ports issues, I'd rather see effort directed there

Given the existing backlog of actual framework and ports issues, I'd rather see effort directed there

As do I. I'd love other people to work on problems I deem important, but we're all volunteers here. What I don't do, however, is turning down contributions I personally find uninteresting.

Anyways, we can at least get the script in and maybe some UGIDs that I find to be removed 10 years ago?

Thanks for working on this!

I agree with mat that there should be a cooldown period before an ID is freed. Perhaps the script could run git blame on the associated line in a file to give us an idea how old the entry is. But then it would only tell us when the entry was added, not when the associated port was removed.

Maybe what we could do is to add a check to pkg that will inform the user if a new ID that's about to be added would conflict with an existing one. Perhaps a check like this is in place already. With a check like this we would give the user a chance to reconfigure the system away from the unsupported legacy.

In D56578#1319231, @ume wrote:

Hi

It seems to me that the extracted lists are incomplete.
At least, "cyrus" has been used by mail/cyrus-imapd* and security/cyrus-sasl2:

• mail/cyrus-imapd312/Makefile#L168-L169
• security/cyrus-sasl2/Makefile.common#L48-L49

This port uses the post-install script to create user and does not define USERS and GROUPS knobs in Makefile. Is there a reason for this?

In D56578#1319257, @arrowd wrote:

This port uses the post-install script to create user and does not define USERS and GROUPS knobs in Makefile. Is there a reason for this?

Yes it is intentional.
In the past, Cyrus requested that we allow users to change their account name because it conflicted with his existing one, and we have addressed this request.

It seems there are "_ypldap" in /etc/{group,passwd}.

In D56578#1297337, @mat wrote:

In D56578#1295345, @arrowd wrote:

I don't think removing entries without checking how long they have been unused is a good idea,

And how long an entry should be unused to make viable for deletion? I doubt we have a policy for that.

I'd say at least 10-15 years before an entry can be recycled.

We don't seem to be running out of free uids and gids, a quick grep tells me we have more than 300 free in each.

We'll have to do this sooner or later and here I am to do that. Why wait for free entries to exhaust?

I'm not convinced this solves a real problem.
I don't see this coming up as a problem in practice.
Given the existing backlog of actual framework and ports issues, I'd rather see effort directed there

As a coincidence i came up with such a detection myself yesterday and found 329 entries in UID + GID to be orphaned. You may not convinced that this solves a real problem - but i would argue that being coherent and correct is one of the foundations of FreeBSD. pgsql for example was removed with upgrade to postgresql12. We now use postgres as user and the lowest version you can install is 14.

There is also no value in keeping these old UIDs around instead of freeing them. If you would argue for people build based on an old ports-tree version, they would also use the old UID/GID files.

Can you elaborate why you suggested to wait 10 years? This arbitrary number looks like chosen to discourage without any reasoning behind it. When i am remember correct titus and hyberv for example were deleted from ports-tree 5 years ago. Why should we keep their UIDs and GIDs that long? hybserv for example was removed in 2021 with the message "Unmaintained and dead upstream, does not build with -fno-common (llvm 11)". What should we keep the UID for?

In the past, Cyrus requested that we allow users to change their account name because it conflicted with his existing one, and we have addressed this request.

I don't quite get it why the post-install script is needed. But I'll add an exception to my script.