Date: Mon, 17 Dec 2018 00:57:51 -0600 From: Scott Bennett <bennett@sdf.org> To: adamw@adamw.org Cc: freebsd-ports@freebsd.org Subject: Re: dependency loop in editors/vim with GTK3 option Message-ID: <201812170657.wBH6vp7i027858@sdf.org> In-Reply-To: <CAP7rwcjDvXpMTFHjF7JxAnnWY8Xsi=sdjOkUUV5q=VEadGErAA@mail.gmail.com> References: <201812150917.wBF9H66V019974@sdf.org> <CAP7rwcjDvXpMTFHjF7JxAnnWY8Xsi=sdjOkUUV5q=VEadGErAA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Adam Weinberger <adamw@adamw.org> wrote:
> On Sat, Dec 15, 2018 at 2:24 AM Scott Bennett <bennett@sdf.org> wrote:
Thanks for your reply.
> >
> > There is a dependency recursion loop in the build process for editors/vim
> > if one selects the GTK3 config menu option. The only way I've found so far to
> > get around this is to choose the GTK2 option instead.
> > With GTK3 selected, graphics/librsvg2 becomes a dependency, which, in
> > turn, is dependent upon lang/vala. lang/vala depends upon devel/dconf, which
> > depends upon devel/gconf2. devel/gconf2 depends upon graphics/graphviz, which
> > depends upon lang/vala! The recursion occurs there and was found by following
> > the instructions in UPDATING for the upgrade to perl5.28 when using portmaster.
> > The command shown in the instructions is "portmaster -f", so the -f forces all
> > dependencies and dependent ports to be rebuilt.
> > As nearly as I can see, this dependency recursion loop breaks any port
> > involving lang/vala when portmaster -f is used. In the case of editors/vim,
> > a usable workaround is to choose gtk2 instead of gtk3, but for many other
> > ports, the perl upgrade's admonition to rebuilt ports that depend upon the
> > perl library to omit -f when using portmaster while providing portmaster a
> > *complete list* of all ports to be built. Provided an acceptable version
> > of lang/vala is already installed, it will be used, and the dependency loop
> > gets skipped over because there is no need to build lang/vala. Of course,
> > if one does that, there is no guarantee that the resulting binaries installed
> > for any of the ports in the recursion loop will function properly, given that
> > they may be based upon obsolete versions of the other ports in the loop.
>
> Hi Scott,
>
> Thanks for the report. A dependency loop is certainly a distressing
> appearance! It can occur when non-default OPTIONS are set, but should
> never occur with default OPTIONS. So, first question: do you have
> non-default OPTIONS for those ports?
Offhand, I don't know. I was going to look, but first I retried running
it with the GTK3 option selected. This time my ports tree was at r487499.
>
> That said---your dependency chain doesn't look right. For example,
> lang/vala depends directly on graphviz, and there is no graphviz
> configuration that could depend directly on vala. lang/vala does not
> depend on dconf, and dconf does not depend on gconf2. Some of the
> dependencies you listed are backwards (gconf2 depends on dconf, and
> dconf depends on vala), but others don't look possible.
It's certainly possible I screwed up my retracement through the
Makefiles. Given that I was having to look through them and the build log via
several vt(9)s and window(1)s, it was a hassle. Nevertheless, the build log
showed iteration after iteration of the recursion clearly up until the time I
stopped it with a ^C.
>
> If you are able to re-trigger the dependency loop, a log would be
> extremely helpful.
>
At r487499 the problem no longer appears. When I ran into the problem,
it was only a day or two's revisions earlier. In any case, the recursion
loop seems to have vanished.
As a side note, when the ports team decides to drop more than one major
deluge of forced port rebuilds close together in time upon an unsuspecting
user community, it would be nice to get a few days' advance notice from the
team, so that users could better plan on having their system(s) tied up for
several hours to several days in the rebuilds.
As another side note, I'd like to express my appreciation for the low
number of new problems that caused port rebuilds to fail this time. The one
I reported here appears to have been short-lived. There were, however, I
encountered six other ports whose rebuilds failed due to compilation errors
or linkage-editing errors. In the past, such massive rebuilds have usually
turned up many more such errors, so I'm quite heartened to see the number
drop so precipitously this time. Hats off to the ports team!
Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet: bennett at sdf.org *xor* bennett at freeshell.org *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
* -- Gov. John Hancock, New York Journal, 28 January 1790 *
**********************************************************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201812170657.wBH6vp7i027858>