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

[Havard Eidnes <he%NetBSD.org@localhost>]

The following reply was made to PR pkg/39734; it has been noted by GNATS.

From: Havard Eidnes <he%NetBSD.org@localhost>
To: gnats-bugs%NetBSD.org@localhost, kre%munnari.OZ.AU@localhost
Cc: pkg-manager%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, 
pkgsrc-bugs%netbsd.org@localhost
Subject: Re: pkg/39734: lang/perl5 upgrade screws (some?) p5-* binary
 packages
Date: Sun, 21 Dec 2008 17:38:23 +0100 (CET)

 Hi,
 
 I see there has been no feedback on this problem logged in GNATS, so
 here is at least some of it.
 
 You said:
 
        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.
 
 Since that time, the following two things have been done:
 
 1) All the modules using perl in some "direct" manner have had their
    package revision numbers bumped.
 2) The perl package's buildlink.mk file has been modified to insert a
    requirement on perl < 5.12.0; this will be inserted in the binary
    packages which use perl.  This will prevent packages built with
    perl 5.10 from being accepted with a future upgraded perl 5.12 (I
    understand perl uses even numbers for "production releases", much
    like Linux does).
 
 Unfortunately, the fix in 2) only really fixes the use of perl binary
 packages built for 5.10 for the (so far theoretical) 5.10 -> 5.12
 transition, and not for the 5.8 -> 5.10 transition -- the horse has
 unfortunately left the barn for the latter one a long time ago,
 because a similar fix should ideally have been done when perl 5.8 was
 imported.
 
 An alternative theoretical fix to 2) could have been to include perl
 5.8's module directories in the search path for modules perl 5.10
 searches for.  However, I hear that would be unsafe, because some of
 the internal APIs are incompatible between perl 5.8 and 5.10, so there
 is no guarantee that the resulting setup would work in all cases.
 Thus, following this route might end up being more trouble than it's
 worth, and the half-way workaround in 1) was chosen instead as a
 "please upgrade" indication.
 
 I'm not sure there is more we can do about this problem given the
 current state.
 
 Best regards,
 
 - H=E5vard