Bug 197131 - net-mgmt/netdot fails to build due to rrdtool path in var/Makefile
Summary: net-mgmt/netdot fails to build due to rrdtool path in var/Makefile
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Raphael Kubo da Costa
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-27 17:37 UTC by web
Modified: 2016-03-05 13:33 UTC (History)
2 users (show)

See Also:


Attachments
netdot-1.0.7_1 (482 bytes, patch)
2015-02-26 22:20 UTC, Nick Hilliard
rakuco: maintainer-approval+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description web 2015-01-27 17:37:10 UTC
In net-mgmt/netdot there is a Makefile in the work/netdot-1.0.7/var/ subdirectory.
In this Makefile, as the first command inside the "if" statement in the "all" target
is the "rrdtool" command.  There are a couple of things wrong with this:

1) rrdtool may or may not be available on the system when attempting to build netdot

2) even if rrdtool is available, it may not be on "root"'s path

This can be fixed by giving a prefix make variable such as ${PREFIX} so that the
real command might translate to /usr/local/bin/rrdtool or wherever ${PREFIX} might
point.  I was unable to build netdot v1.0.7 from this port (even though rrdtool
had been build previously as a dependency) after modifying this line:

   rrdtool ... ... ...

to

   /usr/local/bin/rrdtool ... ... ...

after which the port finished properly and successfully.  Thanks in advance.
Comment 1 Bugzilla Automation freebsd_committer freebsd_triage 2015-01-27 17:37:10 UTC
Maintainer CC'd
Comment 2 Nick Hilliard 2015-01-29 13:52:59 UTC
rrdtool is included in RUN_DEPENDS, so will be in place before installation is attempted by the ports system.

If ${PREFIX}/bin or ${PREFIX}/sbin are not present in ${PATH}, that's a local environment problem, not an installation problem.

Other than that, the default installation prefix in the root level Makefile should definitely include ${PREFIX}:

---
-   PERL        ?= /usr/bin/perl
-   PREFIX      ?= /usr/local/www/netdot
---
+   PERL        ?= ${PREFIX}/bin/perl
+   PREFIX      ?= ${PREFIX}/www/netdot

I'll take a look at patching this up in the next short while
Comment 3 web 2015-01-29 15:12:54 UTC
Since the var/Makefile is executed, the "all" target will attempt to "run"
the command "rrdtool".  While I agree "rrdtool" is normally built prior to
net-mgmt/netdot, there are two reasons why the build might fail:

  1) root (the user) would have to "rehash" to discover the newly
     installed "rrdtool" executable (I run root using tcsh shell)

and

  2) even if for, say, /bin/sh users (root) the "rrdtool" executable
     could be located, there is no guarantee that "rrdtool" would be
     on the user's (root) path

It just seems safer to me to always provide a full path for "bare"
commands in Makefiles.  I do this for /bin/rm, /bin/mv, /bin/ln, etc.
all the time in Makefiles that I create.  This is safer than to
assume that "rm", "mv", and/or "ln" are the same as those at the
above paths.
Comment 4 Nick Hilliard 2015-01-29 16:10:19 UTC
in order for the install target to be executed, the ports system will ensure that the rrdtool command can be found in the default freebsd pkg search path, which is:

/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin

The install target will not proceed unless rrdtool is found.

tcsh rehash only affects the cache on the interactive shell.  If make is executed, it will fork a new $SHELL for CLI commands, so 1. it will probably be /bin/sh and 2. if it's tcsh, it will build up a new path cache on startup anyway.

re: whether it's safer / better practice to use explicit paths, I have no objection to using explicit paths for commands, but only if it's done properly.  To do this properly in netdot, it would be necessary to restructure the Makefiles to use e.g. autoconf, do an explicit search for whatever commands are required, and then write out per-system Makefiles during the installation process.

freebsd-specific hacks are a bad idea because they can't be pushed upstream, as that will break on other systems.  Adding a local patch to the files/ directory adds yet another thing to check when doing package upgrades.

If you want to see this fixed, you should talk to the netdot guys about introducing autoconf support. Otherwise, the freebsd port installation will work fine if you include your default package location in your PATH environment variable.

I'll fix the PREFIX location because that is a bug.
Comment 5 Nick Hilliard 2015-02-26 22:20:21 UTC
Created attachment 153564 [details]
netdot-1.0.7_1

patch to use ${PERL} instead of assuming /usr/bin/perl
Comment 6 Nick Hilliard 2015-02-26 22:21:22 UTC
meant to add that PREFIX is already handled in ${WRKDIR}/Makefile.
Comment 7 Raphael Kubo da Costa freebsd_committer freebsd_triage 2016-02-28 23:22:50 UTC
(In reply to Nick Hilliard from comment #5)
> Created attachment 153564 [details]
> netdot-1.0.7_1
> 
> patch to use ${PERL} instead of assuming /usr/bin/perl

Nick, is this patch ready to be committed? If so, can you set the "maintainer-approved+" flag on it?
Comment 8 Nick Hilliard 2016-03-01 22:42:35 UTC
Approved by:  Nick Hilliard <nick@foobar.org> (maintainer)
Comment 9 commit-hook freebsd_committer freebsd_triage 2016-03-05 13:32:54 UTC
A commit references this bug:

Author: rakuco
Date: Sat Mar  5 13:32:02 UTC 2016
New revision: 410181
URL: https://svnweb.freebsd.org/changeset/ports/410181

Log:
  Be explicit and provide the full path to the perl binary when installing.

  The default value of the PERL variable in the port's Makefile is
  "/usr/bin/perl", be explicit and provide the path to the binary on FreeBSD.

  PR:		197131
  Submitted by:	web@umich.edu
  Approved by:	Nick Hilliard <nick@foobar.org>

Changes:
  head/net-mgmt/netdot/Makefile