Bug 184673 - [bsd.port.mk] abort when a dependency's ports directory doesn't exist
Summary: [bsd.port.mk] abort when a dependency's ports directory doesn't exist
Status: In Progress
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Port Management Team
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-11 01:30 UTC by ultramage
Modified: 2015-06-14 01:15 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ultramage 2013-12-11 01:30:00 UTC
While installing a port, the system will check for dependencies and will try to install any that are missing using the ports tree. If the port's directory does not exist, Mk/bsd.port.mk will just print "No directory for $$prog.  Skipping.." and continue with the main build.

The build will most likely fail somewhere down the line. If you're not actively watching/logging the build output, that will be the only indication that something went wrong. A hypothetical configure script might even work around the missing dependency and silently build an incomplete or inferior product.

I suggest changing all places that do this 'skipping' thing to instead abort the build. Or at least have a way to configure this behavior (although I can't think of a reason why one would want to continue).
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2013-12-11 17:14:07 UTC
Responsible Changed
From-To: freebsd-ports-bugs->portmgr

reclassify and assign.
Comment 2 Mark Linimon freebsd_committer freebsd_triage 2014-06-02 01:57:28 UTC
Infrastructure PR.
Comment 3 Mathieu Arnold freebsd_committer 2015-06-13 02:58:20 UTC
(In reply to viktor.stujber from comment #0)
> While installing a port, the system will check for dependencies and will try
> to install any that are missing using the ports tree. If the port's
> directory does not exist, Mk/bsd.port.mk will just print "No directory for
> $$prog.  Skipping.." and continue with the main build.

Do you have an example of the problem ?
Comment 4 ultramage 2015-06-13 18:59:38 UTC
Sure. I manage my ports tree by using svn update --set-depth=infinity (or =exclude) to add/remove items, so that only the actively used subdirectories are present. I encounter the reported issue everytime a new version of an installed port gains a new dependency, but it can also be triggered on demand:

# mv /usr/ports/devel/libedit /usr/ports/devel/libedit_
# portmaster lang/ruby22

===>>> Gathering dependency list for lang/ruby22 from ports
ruby22-2.2.2,1: "/usr/ports/devel/libedit" non-existent -- dependency list incomplete
ruby22-2.2.2,1: "/usr/ports/devel/libedit" non-existent -- dependency list incomplete
===>>> Initial dependency check complete for lang/ruby22
...
===>   ruby22-2.2.2,1 depends on package: libffi>=0 - found
===>   ruby22-2.2.2,1 depends on file: /usr/local/lib/libcrypto.so.8 - found
===>   ruby22-2.2.2,1 depends on package: libedit>=0 - not found
===>    Verifying install for libedit>=0 in /usr/ports/devel/libedit
     => No directory for libedit>=0.  Skipping..
===>   ruby22-2.2.2,1 depends on file: /usr/local/bin/autoconf-2.69 - found
===>   ruby22-2.2.2,1 depends on shared library: libyaml.so - found
===>  Configuring for ruby22-2.2.2,1
...
===>  Building for ruby22-2.2.2,1
... (10 minutes later)
*** [readline.o] Error code 1
Comment 5 Mathieu Arnold freebsd_committer 2015-06-13 21:15:32 UTC
Ok, and why would you move libedit to libedit_ in the first place ? Of course it is going to break.
Comment 6 ultramage 2015-06-14 01:15:45 UTC
To quickly illustrate the problem, as per your request. The reason for missing subdirectories is in the same post (svn-based ports tree whitelist).

I checked the revision history for bsd.port.mk, to maybe find rationale as to why a dependency install failure due to missing ports entry is not treated as a fatal error.
According to https://svnweb.freebsd.org/ports/head/Mk/bsd.port.mk?r1=9&r2=11 the code responsible for this matches the initial prototype, r11, 1994.