Bug 194940 - ports-mgmt/pkg: 'pkg which' fails for /usr/local/lib/perl5/site_perl/5.16/mach/sys/syscall.ph
Summary: ports-mgmt/pkg: 'pkg which' fails for /usr/local/lib/perl5/site_perl/5.16/mac...
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-pkg (Nobody)
Depends on:
Reported: 2014-11-11 04:34 UTC by Kurt Lidl
Modified: 2014-11-20 14:04 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Kurt Lidl freebsd_committer 2014-11-11 04:34:45 UTC

Comment 1 Kurt Lidl freebsd_committer 2014-11-11 04:37:25 UTC
On a fresh install of 10.1-RC4, with few packages installed, (all from the FreeBSD pkg servers):

host# pkg install -y perl5                                             
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
Checking integrity... done (0 conflicting)
The following 1 packages will be affected (of 0 checked):

New packages to be INSTALLED:
	perl5: 5.16.3_11

The process will require 47 MB more space.
[host] [1/1] Installing perl5-5.16.3_11: 100%
host# pkg which /usr/local/lib/perl5/site_perl/5.16/mach/sys/syscall.ph
/usr/local/lib/perl5/site_perl/5.16/mach/sys/syscall.ph was not found in the database
host# ls -l /usr/local/lib/perl5/site_perl/5.16/mach/sys/syscall.ph
-rw-r--r--  1 root  wheel  27911 Nov 11 04:31 /usr/local/lib/perl5/site_perl/5.16/mach/sys/syscall.ph

Basically, 'pkg which' is failing to tell which package included the syscall.ph file.
Comment 2 Kurt Lidl freebsd_committer 2014-11-11 04:46:51 UTC
I think this is due to the perl5 port not staging the output
of h2ph properly into the 'stage' director when building.

I see it gets installed into /usr/local/... directly, but
there isn't a copy in the work/stage directory as it builds.
Comment 3 Kurt Lidl freebsd_committer 2014-11-11 06:12:34 UTC
I see, after looking at this a bit more, that the problem is twofold:

1) 'pkg which' fails because the the .ph files are generated not
    during the package staging, but rather as part of the post-install
    script that is run when the package is installed.

2) I was doing a 'pkg -c dir ... -y install', and had only enough stuff
   under 'dir' to allow the chroot to succeed.  Which is /bin/sh and
   three shared libraries.  Because there was not a /usr/include directory,
   there were not any .ph files generated.

Both of these are surprising to me.

That files get installed/created and not attributed to a package seems
wrong.  And that the .ph files rely on the /usr/include hierarchy of the
target machine where they are being installed also seems kinda wrong.
Comment 4 Kurt Lidl freebsd_committer 2014-11-11 16:27:21 UTC
I guess the final statement I have on this is that because the
chroot'd environment I was installing the package into had
only /bin/sh available, the entire post-install script for
the package installation failed, yet no notice of this failure
was emitted/logged anywhere.

Nor did the 'pkg' command exit with a non-zero status to indicate
that something had gone wrong.
Comment 5 Mark Linimon freebsd_committer freebsd_triage 2014-11-20 03:56:42 UTC
Fix synopsis and assign.
Comment 6 Mathieu Arnold freebsd_committer 2014-11-20 14:04:57 UTC
Will be fixed when 194969 is committed.