Bug 208575

Summary:	graphics/hugin binary package doesn't install all dependencies
Product:	Ports & Packages	Reporter:	Carlos Carvalho <cartola>
Component:	Individual Port(s)	Assignee:	Greg Lehey <grog>
Status:	Closed FIXED
Severity:	Affects Many People	CC:	w.schwarzenfeld
Priority:	---	Flags:	bugzilla: maintainer-feedback? (grog)
Version:	Latest
Hardware:	amd64
OS:	Any

Description Carlos Carvalho 2016-04-06 11:23:37 UTC

Hi,

I've installed graphics/hugin recently on a FreeBSD 10.2-RELEASE #0 r286666. I did it using pkg install hugin. It installed many dependencies, but when I run hugin after it said something was missing. Then I've installed and another missing thing appeared. After all I've had to install: 

pkg install boost-libs-1.55.0_10
pkg install libpano13-2.9.19_1
pkg install glew-1.13.0
pkg install exiv2-0.24_2,1
pkg install lcms2-2.7_2
pkg install wx28-gtk2-2.8.12_6
pkg install sqlite3-3.11.1

I've reported the package mantainer (greg/grog) and he couldn't find the problem. The port install everything but the package doesn't. I don't know if the problem is in the port framework, package generation or the individual port.

I also don't know if it happens with other packages. I have installed hugin as a first package in a fresh installed system.

Comment 1 commit-hook freebsd_committer

2016-04-08 02:04:41 UTC

A commit references this bug:

Author: grog
Date: Fri Apr  8 02:04:06 UTC 2016
New revision: 412707
URL: https://svnweb.freebsd.org/changeset/ports/412707

Log:
  Correct errors in pkg-plist.

  PR:		208575
  Submitted by:	Don Lewis

Changes:
  head/graphics/hugin/Makefile
  head/graphics/hugin/pkg-plist

Comment 2 Greg Lehey freebsd_committer

2016-04-08 02:32:05 UTC

Commit r412707 fixes a problem with the pkg-plist for this port.
There is some reason to hope that the resultant package will then
install dependencies correctly.  I'll wait for availability of the
package.

Comment 3 Walter Schwarzenfeld 2018-01-13 06:23:36 UTC

Forget to close?

Comment 4 Walter Schwarzenfeld 2018-02-12 22:29:50 UTC

No statement nearly two years, so I assume it is fixed and close here.