pkg/41711: textproc/rubber installs a file that is missing from PLIST

[kre%munnari.OZ.AU@localhost]

>Number:         41711
>Category:       pkg
>Synopsis:       textproc/rubber installs a file that is missing from PLIST
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jul 13 13:05: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:
        The file-check test that pkgsrc makes when PKG_DEVELOPER=yes
        fails for textproc/rubber

>How-To-Repeat:
        I use pkg_comp with libkver and NetBSD 4.0 release sets installed
        (except for x*, I use pkgsrc modular xorg).  I doubt that any of that
        is relevant to this problem - except that pkg_comp causes
        PKG_DEVELOPER=yes which is what enables the file-check tests.

        Expect to see ...

=> Registering installation for rubber-1.1nb2
rubber-1.1nb2 requires installed package python25-2.5.4nb1
rubber-1.1nb2 requires installed package teTeX-bin-3.0nb34
=> Checking file-check results for rubber-1.1nb2
ERROR: ************************************************************
ERROR: The following files are in /usr/pkg but not in the PLIST:
ERROR:         /usr/pkg/share/rubber/rubber-1.1-py2.5.egg-info

>Fix:
        I'd assume the offending file either needs to not get installed
        if it isn't needed (no idea) or to be added to the PLIST
        which I would guess would need some magic handling, as it has
        the python version number embedded in it, and I would guess that
        just comes from whichever (of the allowed) python version happens
        to be insalled and thus is used by this package.   Since there seems
        to be no python version restriction in the Makefile, I assume that
        the "py2.5" part of the filename might end up being just about
        anyyhing (I also assume that there's a standard method available to
        deal with this problem...)