Just to make sure I'm on the same page, because to me having FreeBSD-blocklist-lib and FreeBSD-blocklist would be like having FreeBSD-ssh and FreeBSD-ssh-lib.
I do not see a working FreeBSD-ssh package without FreeBSD-blocklist, that is, I was going to ask you if we should add a deps block to ssh.ucl?
On the other hand, if we decide to split, where should we stop? Should FreeBSD-blocklist be split into FreeBSD-blocklist-client and FreeBSD-blocklist-daemon?
At this point I'm not opposed nor in favor, I just need to gather more information. Thank you for taking a look at this issue.

In D53605#1223871, @jlduran wrote:

Just to make sure I'm on the same page, because to me having FreeBSD-blocklist-lib and FreeBSD-blocklist would be like having FreeBSD-ssh and FreeBSD-ssh-lib.

nothing links against the libraries in the ssh package (or at least i haven't found anything that does yet, while auditing this) so having a separate ssh-lib package would not be useful. the use-case here is someone wants to run sshd, or use the ssh client, but they don't use/want blocklistd - so why do they need to install the blocklistd daemon, the rc.d script, etc? having a blocklist-lib package means ssh can depend on blocklist-lib instead of blocklist[0], and only users who actually want to run blocklistd need to install the blocklist package.

[0] note that pkg adds this dependency automatically

I do not see a working FreeBSD-ssh package without FreeBSD-blocklist

sshd works fine without blocklistd running, doesn't it? i don't run blocklistd on any of my systems, since i don't accept ssh connections from the Internet. as long as libblocklist is present, sshd will work fine, and just silently fail to report failures to blocklistd, just like it would if blocklistd was installed but not running.

On the other hand, if we decide to split, where should we stop? Should FreeBSD-blocklist be split into FreeBSD-blocklist-client and FreeBSD-blocklist-daemon?

that would not be useful as it doesn't make sense to install blocklistd without the client utility to manage it. or IOW, everyone who wants "blocklist-daemon" would also want "blocklist-client".

In D53605#1223872, @ivy wrote:

In D53605#1223871, @jlduran wrote:

Just to make sure I'm on the same page, because to me having FreeBSD-blocklist-lib and FreeBSD-blocklist would be like having FreeBSD-ssh and FreeBSD-ssh-lib.

nothing links against the libraries in the ssh package (or at least i haven't found anything that does yet, while auditing this) so having a separate ssh-lib package would not be useful. the use-case here is someone wants to run sshd, or use the ssh client, but they don't use/want blocklistd - so why do they need to install the blocklistd daemon, the rc.d script, etc? having a blocklist-lib package means ssh can depend on blocklist-lib instead of blocklist[0], and only users who actually want to run blocklistd need to install the blocklist package.

[0] note that pkg adds this dependency automatically

I do not see a working FreeBSD-ssh package without FreeBSD-blocklist

sshd works fine without blocklistd running, doesn't it? i don't run blocklistd on any of my systems, since i don't accept ssh connections from the Internet. as long as libblocklist is present, sshd will work fine, and just silently fail to report failures to blocklistd, just like it would if blocklistd was installed but not running.

On the other hand, if we decide to split, where should we stop? Should FreeBSD-blocklist be split into FreeBSD-blocklist-client and FreeBSD-blocklist-daemon?

that would not be useful as it doesn't make sense to install blocklistd without the client utility to manage it. or IOW, everyone who wants "blocklist-daemon" would also want "blocklist-client".

Right, that's the answer I feared.
Perhaps the discussion can be if we want to make WITHOUT_BLOCKLIST the default? That would be understandable, since it has a low usage rate, I would approve that.

The problem I see with this proposal is:
In your sshd_config file, there is a #UseBlocklist no line, let's suppose a user now decides to use blocklist, after uncommenting the line, and changing it to yes, the user should make sure that FreeBSD-blocklist package is installed? It's like shipping an incomplete SSH program.

I'll leave the decision to the pkgbase group. It'll be OK either way.

In D53605#1223886, @jlduran wrote:

Perhaps the discussion can be if we want to make WITHOUT_BLOCKLIST the default? That would be understandable, since it has a low usage rate, I would approve that.

i would definitely be opposed to that; blocklistd is useful functionality and requiring people to rebuild the system from source to use it would be user-hostile. that's the opposite of what we're trying to achieve with pkgbase, which is that it should not be necessary to rebuild the system from source to add/remove optional components.

the proposed blocklist-lib package is tiny, since libblocklist is only 12KB, so installing it for people who don't use it is no real overhead.

In your sshd_config file, there is a #UseBlocklist no line, let's suppose a user now decides to use blocklist, after uncommenting the line, and changing it to yes, the user should make sure that FreeBSD-blocklist package is installed? It's like shipping an incomplete SSH program.

X11Forwarding doesn't work unless you install X.org from ports; should we disable that as well unless the user rebuilds from source?

it seems reasonable to me that if an SSH feature requires an external feature to work, you have to install that feature. it's not that the SSH package is incomplete, it's simply that SSH interacts with things that aren't part of SSH.

In D53605#1223887, @ivy wrote:

In D53605#1223886, @jlduran wrote:

Perhaps the discussion can be if we want to make WITHOUT_BLOCKLIST the default? That would be understandable, since it has a low usage rate, I would approve that.

i would definitely be opposed to that; blocklistd is useful functionality and requiring people to rebuild the system from source to use it would be user-hostile. that's the opposite of what we're trying to achieve with pkgbase, which is that it should not be necessary to rebuild the system from source to add/remove optional components.

I meant it without hostility. Just like we have FreeBSD-kernel-generic and FreeBSD-kernel-minimal, we could have FreeBSD-ssh-blocklist and FreeBSD-utilities-blocklist.

the proposed blocklist-lib package is tiny, since libblocklist is only 12KB, so installing it for people who don't use it is no real overhead.

So FreeBSD-blocklist is ~47KB, I'm not too worried about the size. What you are proposing is an interesting packaging decision. It concerns not too much about blocklist itself, but how to package it. That's why I think it's better if you or pkgbase take that decision.

In your sshd_config file, there is a #UseBlocklist no line, let's suppose a user now decides to use blocklist, after uncommenting the line, and changing it to yes, the user should make sure that FreeBSD-blocklist package is installed? It's like shipping an incomplete SSH program.

X11Forwarding doesn't work unless you install X.org from ports; should we disable that as well unless the user rebuilds from source?

I don't know if this is a fair comparison, FreeBSD does not ship X11 with the base system, and the intention of this setting is different.

it seems reasonable to me that if an SSH feature requires an external feature to work, you have to install that feature. it's not that the SSH package is incomplete, it's simply that SSH interacts with things that aren't part of SSH.

Please go ahead if my decision is hindering you from keeping the stride, I still cannot fathom a use case wanting just the libs of blocklist, but not blocklist.