Differential D53605
lib/libbl[ao]cklist: Use LIB_PACKAGE Authored by ivy on Nov 6 2025, 12:39 AM. Tags None Referenced Files
Details This avoids e.g. utilities or ssh depending on the full blocklist This change moves files between packages so, until we have a proper MFC after: never
Diff Detail
Event TimelineComment Actions 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. Comment Actions 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
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.
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". Comment Actions Right, that's the answer I feared. The problem I see with this proposal is: I'll leave the decision to the pkgbase group. It'll be OK either way. Comment Actions 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.
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. Comment Actions 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.
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.
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.
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. Comment Actions Considering that if one sets UseBlocklist yes and blocklistd is not installed at all, will just result with the same behaviour as with blocklistd installed but not started I think the is ok to split the packages this way. |