Sebastian Benoit <benno@openbsd.org> wrote:

> Claudio Jeker(cjeker@diehard.n-r-g.com) on 2025.04.25 13:31:32 +0200:
> > On Fri, Apr 25, 2025 at 11:36:50AM +0100, Stuart Henderson wrote:
> > > On 2025/04/25 12:04, Henning Brauer wrote:
> > > > * Stuart Henderson <stu@spacehopper.org> [2025-04-25 03:25]:
> > > > > On 2025/04/24 10:38, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
> > > > > > This is great!  Some quick testing shows it correctly sees
> > > > > > all the Fortinet and Juniper hardware on my networks.
> > > > > > 
> > > > > > But I would suggest just calling it lldp[d] right from the
> > > > > > start.  I don't see a conflict as it's makes no sense to 
> > > > > > run both this and ports at the same time.  And if they
> > > > > > are both installed, the ports cli names don't collisde
> > > > > > with this one's.
> > > > > 
> > > > > The rc.d scripts conflict.
> > > > 
> > > > then the ports one needs to be adjusted.
> > > > 
> > > > our ntpd is ntpd, not ontpd.
> > > 
> > > yes and we had a problem with that around 5.0-5.1
> > > 
> > > > our ldapd is ldapd, not oldapd.
> > > 
> > > no conflict
> > > 
> > > > our smtpd is smtpd, not osmtpd.
> > > 
> > > no conflict
> > > 
> > > > our bgpd is bgpd, not obgpd.
> > > 
> > > the possibly-conflicting rc script was named quagga_bgpd from the start
> > > 
> > > > and so on and so on.
> > > 
> > > the rc-script could be renamed, but:
> > > 
> > > 1. what to?
> > > 
> > > 2. unless it's renamed in the release _before_ this is added, upgrades
> > > will be broken. user updates base from a version with ports lldpd
> > > installed to a version with lldpd from base, so overwriting rc.d/lldpd.
> > > updating packages at that point will _remove_ the rc.d/lldpd script.
> > > 
> > > if we want to reuse existing names of things from ports in base we
> > > could really do with a separate namespace for ports and base rc.d scripts.
> > 
> > Would it be acceptable to use lldpd as program name but use rc.d/lldp as
> > startup script?
> > 
> > The only other problem point would be the file in /var/run but I think
> > that implies that someone wants to run both tools at the same time which
> > IMO makes little sense and people can then use an overwrite to toggle the
> > control socket path.
> > 
> > I would really like to see dlg's tool in our tree and it seems this is the
> > main pain point.
> 
> Does the daemon need to have a "d" at the end?
> 
> If not, how about
> 
> lldp	- the daemon binary
> lldpctl	- the tool
> lldp	- rc-script
> _lldp	- username

I think we've been here before.  When we write our own components, eventually
people stop using the ports components because ours are good enough.

Sometimes, it was an external component, which we modified iteratively until
we had to throw it away, and our own system matured once we dogfooded it.

This lldp is not as feature complete, but it's privsep design is stronger,
perhaps even strong enough that it can be run by default.  It probably doesn't
need to be feature complete.  lldp protocol is supposed to, over time, replace
all the other legacy things like cdp.  Noone wants a daemon on OpenBSD that
does all the features.  Noone wants a speaker on a vendor device that speaks
their custom protocol, since so many have had scary bugs, and they don't
interoperate.  So can we say, bye by legacy, at the same time?  Us making such
a decision also partly feeds into the internet culture and allows others to
consider making the same decision (lldp, only).

With the ports lldp code, running it by default is not going to happen.

So I'm confused about why we are bending over backwards for a ports daemon.

Let's just take over the naming and keep it simple.