pkg/39734: lang/perl5 upgrade screws (some?) p5-* binary packages

[kre%munnari.OZ.AU@localhost]

>Number:         39734
>Category:       pkg
>Synopsis:       lang/perl5 upgrade screws (some?) p5-* binary packages
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Oct 12 12:50:00 +0000 2008
>Originator:     Robert Elz
>Release:        NetBSD 4.0_STABLE  (pkgsrc current within last 6 hours)
>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:
        lang/perl5 has just been upgraded - and now looks for add-on
        modules in different places than it did before.  p5-* packages
        built with the new perl will, I assume, go into the appropriate
        places, but binary packages built earlier do not.   Yet, there's
        no indication (aside when other things fail) that there is any
        reason to upgrade the binary package.

>How-To-Repeat:
        After perl was (successfully) upgraded, I happened to be upgrading
        lang/mono - I use pkg_comp with NetBSD 3.0 release sets (and libkver)
        but I can't believe that's in any way related.

        When this build started perl5 5.10.0 would have been installed
        in the sandbox already, that upgrade had not long happened.

        The build all starts out looking fine ...

PKG_COMP ==> Mounting sandboxed filesystems
PKG_COMP ==> Checking if pkg_install is up to date
PKG_COMP ==> Building and installing lang/mono
===> Binary install for mono-2.0nb1
=> Installing mono-2.0nb1 from /pkg_comp/packages/All
pkg_add: no pkg found for 'mono-2.0nb1', sorry.
pkg_add: 1 package addition failed
=> No binary package found for mono-2.0nb1; installing from source.
=> Bootstrap dependency digest>=20010302: found digest-20080510
=> Checksum SHA1 OK for mono-2.0.tar.bz2
=> Checksum RMD160 OK for mono-2.0.tar.bz2
===> Installing dependencies for mono-2.0nb1
=> Build dependency p5-XML-Parser-[0-9]*: NOT found
=> Verifying bin-install for ../../textproc/p5-XML-Parser
===> Binary install for p5-XML-Parser-[0-9]*
=> Installing p5-XML-Parser-[0-9]* from /pkg_comp/packages/All
p5-XML-Parser-2.36 successfully installed.
=> Returning to build of mono-2.0nb1
=> Build dependency libtool-base>=1.5.18nb5: found libtool-base-1.5.24nb6
=> Build dependency bison>=1.0: NOT found
=> Verifying bin-install for ../../devel/bison
===> Binary install for bison>=1.0
=> Installing bison>=1.0 from /pkg_comp/packages/All
m4-1.4.11nb1: registering info file /usr/pkg/info/m4.info
bison-2.3: registering info file /usr/pkg/info/bison.info
bison-2.3 successfully installed.
=> Returning to build of mono-2.0nb1

        There are lots more dependencies all successfully installed.
        No problem there (notice that p5-XML-Parser-2.36 was one of
        the dependencies successfully installed).

        p5-XML-Parser (the pkgsrc entry) was last updated Nov 2007,
        that's when the binary package that was just installed was
        built for me ...    2.36 is still the current version.

-rw-r--r--  1 root  wheel  203761 Nov 30  2007 
/local/packages/3.0/All/p5-XML-Parser-2.36.tgz

        /local/packages/3.0 is /pkg_comp/packages in the sandbox.

        Eventually we get to ...

=> Returning to build of mono-2.0nb1
===> Overriding tools for mono-2.0nb1
===> Extracting for mono-2.0nb1
===> Patching for mono-2.0nb1
=> Applying pkgsrc patches for mono-2.0nb1
=> Fixing relative prefix
INFO: [subst.mk:fix-prefix] Nothing changed in ./mono-uninstalled.pc.in.
INFO: [subst.mk:fix-prefix] Nothing changed in ./data/cecil.pc.in.
INFO: [subst.mk:fix-prefix] Nothing changed in ./data/dotnet.pc.in.
INFO: [subst.mk:fix-prefix] Nothing changed in ./data/dotnet35.pc.in.
INFO: [subst.mk:fix-prefix] Nothing changed in ./data/smcs.pc.in.
=> Fixing mcs default prefix
=> Fixing configuration files install dir
===> Creating toolchain wrappers for mono-2.0nb1
===> Configuring for mono-2.0nb1

        (etc) - all fine.   Later ...

configure: creating ./config.status
config.status: creating Makefile
config.status: creating include/Makefile
config.status: creating include/private/Makefile
config.status: creating doc/Makefile
config.status: executing depfiles commands
config.status: executing default commands

        mcs source:    $(top_srcdir)/mcs
        olive source:  

        GC:          included
        TLS:         pthread
        SIGALTSTACK: no
        Engine:      Building and using the JIT
        2.0 Beta:    yes
        2.1 Alpha:   no
        JNI support: IKVM Native
        libgdiplus:  assumed to be installed
        zlib:        bundled zlib
        oprofile:    no
        BigArrays:   no
        


=> Modifying libtool scripts to use pkgsrc libtool
WARNING: *** Please consider adding fortran to USE_LANGUAGES in the package 
Makefile.
===> Building for mono-2.0nb1
/usr/pkg/bin/gmake  all-recursive
gmake[1]: Entering directory `/pkg_comp/obj/pkgsrc/lang/mono/default/mono-2.0'

        Still all as would be expected.  Lots of successfull compilation
        follows (with the occasional warning, I'm assuming they're normal)
        Until ...

Making all in cil
gmake[3]: Entering directory 
`/pkg_comp/obj/pkgsrc/lang/mono/default/mono-2.0/mono/cil'
/usr/pkg/bin/perl ./make-opcodes-def.pl ./cil-opcodes.xml opcode.def.tmp
Can't locate XML/Parser.pm in @INC (@INC contains: 
/usr/pkg/lib/perl5/site_perl/5.10.0/i386-netbsd-thread-multi 
/usr/pkg/lib/perl5/site_perl/5.10.0 
/usr/pkg/lib/perl5/vendor_perl/5.10.0/i386-netbsd-thread-multi 
/usr/pkg/lib/perl5/vendor_perl/5.10.0 /usr/pkg/lib/perl5/vendor_perl 
/usr/pkg/lib/perl5/5.10.0/i386-netbsd-thread-multi /usr/pkg/lib/perl5/5.10.0 .) 
at ./make-opcodes-def.pl line 16.
BEGIN failed--compilation aborted at ./make-opcodes-def.pl line 16.
gmake[3]: *** [opcode.def] Error 2
gmake[3]: Leaving directory 
`/pkg_comp/obj/pkgsrc/lang/mono/default/mono-2.0/mono/cil'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory 
`/pkg_comp/obj/pkgsrc/lang/mono/default/mono-2.0/mono'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/pkg_comp/obj/pkgsrc/lang/mono/default/mono-2.0'
gmake: *** [all] Error 2
*** Error code 2

Stop.
make: stopped in /usr/pkgsrc/lang/mono
*** Error code 1

        which is not all that surprising, as XML/Parser.pm cannot
        possibly be in a perl5/5.10.0 directory, perl 5.10 dit not
        exist in November 2007 when the p5-XML-Parser package was
        created.  Instead, it got installed as ...

-r--r--r--  1 root  wheel  27103 Nov 20  2007 
/usr/pkg/lib/perl5/vendor_perl/5.8.0/i386-netbsd-thread-multi/XML/Parser.pm

        Under the 5.8.0 sub-dir.   That's where it was before, and as
        nothing has happened to change it, that's where it remains.

>Fix:
        Obviously the simple workaround would be for me (everyone I assume)
        to simply delete all the p5-* packages I have built, and allow them
        to be rebuilt as needed.

        But when rebuilt, aside from the build date (and internal path
        names, etc) they will be indistinguishable from the new ones.
        Other binary packages that I have depend upon p5-* and some
        of those may possibly be still expecting stuff to live in
        the places they existed when the other binary packages were
        built.

        I'm assuming that the short term fix is going to be one GIANT
        revbump on all of the p5 packages, and everything that depends
        upon them, so the whole world gets rebuilt with perl 5.10
        instead of all assuming 5.8

        Longer term, a better fix is needed - when binary packages are
        built that depend upon a specific version of some other package,
        they must be made to only successfully install when that particular
        version exists, and to fail otherwise.  And their names must include
        a reference to the version number of the underlying package.

        That is, if the p5-XML-Parser binary I have failed to insatll,
        as it found perl5.10 instead of perl 5.8 that would be OK, then
        it would just have been rebuilt.   But when rebuilt, it must
        produce a differnt binary package (filename) than the existing
        one, or the existing one would be destroyed, and anything else
        I have that depends upon the old version of p5-XML-Parser would
        be unable to work (and that one, now perl 5.8 is gone, is
        effectively impossible to rebuild.)

        I suspect this PR is rather related to pkg/35012 ...  (but the
        short term revbump fix is needed quickly, rather than just
        sometime in the distant future as for 35012.)