From owner-freebsd-current@FreeBSD.ORG Fri Mar 20 14:48:18 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8DF92DF6 for ; Fri, 20 Mar 2015 14:48:18 +0000 (UTC) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 41FD974C for ; Fri, 20 Mar 2015 14:48:18 +0000 (UTC) Received: by iecvj10 with SMTP id vj10so94598713iec.0 for ; Fri, 20 Mar 2015 07:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jUdb69tWF361idFnXN+42xnl+VKfySV0OMgz2JDaAg0=; b=fWN9/0oD6NGDTT/pB3GiqE8o6EQKYFxEoYBzdPgLZ3rXlZxjAVLT4KABLsElJIOl+j rb9oHUD5NNpPulCcxf7S9FHMzID5ypOLUi5KxPshBsk5sQ0EwrQT2Ij6tolopmcUhZG8 NUlZ4X4fL9/8FKtVvS/PEJ2iocCIwxglxiNKQJtTPuNHXFMwYmv6938Ge3ZRkx+xvBbU OB95hy2CEAodxBMkA9hnAXwTOtxja1ZeBRP8UW4bAtsae/9J3fsnV5Ns9n9z9kFEm1br QIdFWqxEC3h7O/XFqmReqHbnGYxMlUYdPiVuy3qgRk0Lvo9kxLXr5Y0l4LCd2lMgGVqw Izfw== X-Received: by 10.107.18.226 with SMTP id 95mr131749208ios.84.1426862897685; Fri, 20 Mar 2015 07:48:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.55.167 with HTTP; Fri, 20 Mar 2015 07:47:57 -0700 (PDT) In-Reply-To: <2A8C0814-E644-4350-85B8-17B468D79BFF@gmail.com> References: <64AF7708-217B-4AC0-A47A-AD1B0BFF7EDC@gmail.com> <885DA4D0-9644-4F06-97C9-04EAD7B4958C@gmail.com> <98CF988A-D9DB-49AD-8CFF-3B438F892730@gmail.com> <2A8C0814-E644-4350-85B8-17B468D79BFF@gmail.com> From: Miguel Clara Date: Fri, 20 Mar 2015 14:47:57 +0000 Message-ID: Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 14:48:18 -0000 On Thu, Feb 26, 2015 at 2:52 AM, Garrett Cooper wrote: > > On Feb 25, 2015, at 18:08, Kevin Oberman wrote: > > On Wed, Feb 25, 2015 at 2:30 PM, Garrett Cooper > wrote: > >> On Feb 25, 2015, at 14:19, Miguel Clara 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 i= n >> "NETWORKING" recently? >> > >> > Hum: >> > >> https://svnweb.freebsd.org/base/head/etc/rc.d/NETWORKING?r1=3D275299&r2= =3D278704 >> > >> > 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 th= is >> 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 w= hen >> a circular dependency is encountered, a dichotomy occurs. >> >> Now you know why I=E2=80=99m so curious about all of this stuff. >> >> When I was working on ^/projects/building-blocks, I was able to move mos= t >> of these pieces around by changing REQUIRE: to BEFORE:, but I noticed th= at >> it changes the rcorder a bit, so I haven=E2=80=99t 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 befo= re >> 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=E2=80=99ve seen at several jobs, getting developers= to fail, >> then retry is hard :(=E2=80=A6). >> >> 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 an= y > nameserver (or kerberos or whatever provider), it is not an issue. As lon= g > as rcorder finds a provider, it will be used to set the order, but the la= ck > 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 th= e > 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'm going to post a fix up for this on arch@/rc@ because it needs to be > solved in a saner way -- especially for systems that are pedantic about > rcorder, like our version at $work. > > I re-sync my source and noticed the change while doing the mergemaster part... with this I can now change dnscrypt to: @@ -4,7 +4,7 @@ # # PROVIDE: dnscrypt_proxy # REQUIRE: SERVERS cleanvar -# BEFORE: named local_unbound unbound +# BEFORE: DNS And this makes the rcorder ok for dnscrypt-proxy