Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy"

On Wed, 25 Feb 2015 18:52:35 -0800, Garrett Cooper <yaneurabeya_at_gmail.com> wrote:

> 
> > On Feb 25, 2015, at 18:08, Kevin Oberman <rkoberman_at_gmail.com> wrote:
> > 
> >> On Wed, Feb 25, 2015 at 2:30 PM, Garrett Cooper <yaneurabeya_at_gmail.com> wrote:
> >> On Feb 25, 2015, at 14:19, Miguel Clara <miguelmclara_at_gmail.com> wrote:
> >> 
> >> ...
> >> 
> >> > I noticed this too, but in that case why doesn't it affect all users? (or all the ones using dnscrypt+local_unbound) maybe something changed in "NETWORKING" recently?
> >> >
> >> > Hum:
> >> > https://svnweb.freebsd.org/base/head/etc/rc.d/NETWORKING?r1=275299&r2=278704
> >> >
> >> > Interesting, as I am using the most recent version which does not REQUIRE local_unbound
> >> >
> >> > I'm even more confused now :|
> >> >
> >> >
> >> > So it has to come after SERVERS but before local_unbound. But NETWORKING depends on local_unbound they are both dependent on NEWORKING which has to be after SERVERS. Can you say fubar! Clearly broken. And this means that removing SERVERS will re-shuffle the order more appropriately.
> >> >
> >> > It seems that the behavior of rcorder is not as documented as well as being undefined when circular dependencies occur. The man page says that rcorder aborts when it encounters a circular dependency, but that is not the case. It probably is best that it not die, but that leaves things in an unknown and inconsistant state, which is also a very bad idea. I guess when a circular dependency is encountered, a dichotomy occurs.
> >> 
> >> Now you know why I’m so curious about all of this stuff.
> >> 
> >> When I was working on ^/projects/building-blocks, I was able to move most of these pieces around by changing REQUIRE: to BEFORE:, but I noticed that it changes the rcorder a bit, so I haven’t been super gung ho in implementing my change.
> >> 
> >> I think there are a couple bugs present on 9-STABLE/10-STABLE/11-CURRENT:
> >> 
> >> - Things go awry if named is removed/not installed.
> >> - Things go awry if local_unbound is removed (which would have been the case if the rc.d script was removed from your system, which existed before my changes).
> >> - Other rc.d scripts not being present might break assumptions.
> >> 
> >> I need to create dummy providers for certain logical stages (DNS is one of them) to solve part of this problem and provide third parties with a mechanism that can be depended on (I wish applications were written in a more robust manner to fail gracefully and retry instead of failing flat on their face, but as I’ve seen at several jobs, getting developers to fail, then retry is hard :(…).
> >> 
> >> Another short-term hack:
> >> 
> >> Install dummy/no-op providers so the ordering is preserved, then remove the hacks after all of the bugs have been shaken out.
> >> 
> >> Thanks!
> > 
> > Garret, 
> > 
> > Also undocumented (except in rcorder.c) is that the lack of a provider is not an error. This effectively makes a list of providers into an OR. So, for name service the normal list is "named local_unbound unbound" and any will work for ordering and having none is a no-op, so if you don't run any nameserver (or kerberos or whatever provider), it is not an issue. As long as rcorder finds a provider, it will be used to set the order, but the lack of any or all providers just means that the specified provider is ignored and if a REQUIRES or BEFORE lists no existing providers, the statement is simply ignored.
> > 
> > The real problem is that there is no defined rule for behavior in the event of a circular dependency and any change to any decision point in the ordering process may change the way the ordering flips. That is why these things are such a royal pain to debug. A change in any rc.d script may cause the ordering of seemingly unrelated scripts to change, perhaps drastically, and the error messages, while not misleading, is only a starting point in tracking this down. This means there may be time bombs that break working ports without their being touched or even re-installed. And the triggering change my, itself be correct.
> 
> Or etc/rc.d/named...
> 
> PROVIDES: DNS
> 



I don't know if this is adding not-relevancy to this thread or not... I've a long persistent "dbus-daemon*" "*uuid*"
(names approximate, not saved during boot) two "start ..." failures during rc...  despite reinstalling the ports
and dependencies, particularly the .so. files mentioned (not included here...  

uuidd_enable="YES"   (e2fsprogs* )
dbus_enable="YES"  (*dbus*) 

beginning v9 OR v10 ( not recollecting enough...) and persisting thenceforth.

Maybe those two could also be similarly fixed to this thread's one
Despite not being in use day-to-day... nor particularly relevant... installed only conventionally.