pkgsrc-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
pkg/41787: archivers/zziplib has PLIST (or probably other more serious) problems
>Number: 41787
>Category: pkg
>Synopsis: archivers/zziplib has PLIST (or probably other more serious)
>problems
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: pkg-manager
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Jul 26 19:50:00 +0000 2009
>Originator: Robert Elz
>Release: NetBSD 4.0_STABLE
>Organization:
Prince of Songkla University
>Environment:
System: NetBSD jade.coe.psu.ac.th 4.0_STABLE NetBSD 4.0_STABLE
(JADE-1.696-20080517) #9: Fri May 23 18:55:13 ICT 2008
kre%jade.coe.psu.ac.th@localhost:/usr/obj/4/kernels/JADE i386
Architecture: i386
Machine: i386
>Description:
After the recent upgrade, archivers/zziplib generates errors
from the file-check test that pkgsrc makes with PKG_DEVELOPER=yeso
However, the file names it complains about (which really do get
installed) suggest that perhaps the real problem is with libtool,
or something like that.
>How-To-Repeat:
I am using pkg_comp with libkver and NetBSD 4.0 release sets installed
(except x* - using pkgsrc modular xorg instead, but that's irrelevant).
Building installing and making a binary package with PKG_DEVELOPER=yes
(which pkg_comp makes happen) results in...
hecking file-check results for zziplib-0.13.56
ERROR: ************************************************************
ERROR: The following files are in /usr/pkg but not in the PLIST:
ERROR: /usr/pkg/lib/libzzip*.so.10
ERROR: /usr/pkg/lib/libzzip*.so.11
ERROR: /usr/pkg/lib/libzzip*.so.12
*** Error code 1
Those files, really do get installed (they're present
in /usr/pkg).
Earlier in the build log I see ...
===> Installing for zziplib-0.13.56
=> Generating pre-install file lists
/usr/pkg/lib: ln -s libzzip*.so.13 libzzip*.so.10
/usr/pkg/lib: ln -s libzzip*.so.13 libzzip*.so.11
/usr/pkg/lib: ln -s libzzip*.so.13 libzzip*.so.12
which looks like some kind of weird attempt to make
applications that linked against earlier versions of
libzzip continue to work with the current version.
Aside from the ln command run that way being absurd
(if there isn't a single existing libzzip*.so.10 file, etc)
it isn't the right thing to do - if the major number of
the lib has changed, that should mean that the library is
incompatible with earlier versions, and applications linked
against earlier versions of the library simply need to be
recompiled (at very least, relinked) in order to work.
Or, the old libzzip.so.10 (etc) libraries can simply be
left in place.
>Fix:
No idea, I took a look and couldn't see where this
nonsense is happening (but it does, repeatedly).
Home |
Main Index |
Thread Index |
Old Index