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

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!