[arch-dev-public] [Bulk] Re: Updated perl 5.10.0

K. Piche kpiche at rogers.com
Fri Jan 4 22:30:25 EST 2008


On Wed, 2008-01-02 at 23:10 -0500, K. Piche wrote:
> On Wed, 2008-01-02 at 20:56 -0600, Dan McGee wrote:
> > On Jan 2, 2008 8:10 PM, K. Piche <kpiche at rogers.com> wrote:
> > > > > Seems that there's a symbol that used to be in some perl lib but isn't
> > > > > anymore (Perl_Tstack_sp_ptr).
> > > > >
> > > > > I can create a bug if need be.
> > > >
> > > > Same issue for urxvt:
> > > > http://bugs.archlinux.org/task/9075
> > > >
> > > > -Dan
> > >
> > > Yeah, it's cause of the move to perl 5.10.0.  I had the same symbol
> > > problem with perlxml - a rebuild will fix it.  Adding urxvt to the list.
> > 
> > Thanks for the good work here! Urxvt working fine now, and running
> > perl 5.10.0. If all is well I'll give it a signoff in a couple of
> > days.
> > 
> > Can you perhaps point the rest of us in the right direction as to what
> > we need to do to packages to make them comply with the new perl
> > policy? That wiki page looks good (not sure how recent it has been
> > updated), but is there an easy trick to get modules to install in the
> > vendor directory? I know I have a few packages that install stuff into
> > site_perl instead of vendor_perl, and I'm sure others do as well.
> > 
> > -Dan
> 
> Sure, no problem.  There are 2 main things that need to be taken care of
> for official perl modules:
> 
> - files installed in the vendor directories
> - man pages should be named with .[0-9]pm extensions so they don't
> conflict with CPAN/CPANPLUS installed packages.  There is no distinction
> between vendor/site/core in regards to man pages
> 
> Most of our official modules use the 'perl Makefile.PL' method to build
> and the perlxml PKGBUILD would be a good example of this.  The other
> method 'perl Build.PL' I'm figuring out now with sdl-perl (need frozen
> bubble!).
> 
> Makefile.PL stuff becomes:
>   # install module in vendor directories.
>   perl Makefile.PL INSTALLDIRS=vendor || return 1
>   make MAN1EXT=1p MAN3EXT=3pm || return 1
>   make install MAN1EXT=1p MAN3EXT=3pm DESTDIR=${startdir}/pkg || return
> 1


I've rethought how I'm going to handle the man page extension stuff so
packagers won't need to set man1ext and man3ext like this.  I'm going to
try tweaking Config.pm after the perl pkg 'make install'.  So don't
convert all your builds yet although the above will still work.

Also the Build.PL stuff is now:
  perl Build.PL installdirs=vendor destdir=${startdir}/pkg \
                --config man1ext=1p --config man3ext=3pm
  perl Build
  perl Build install

With man extension settings for now.  Note that perl-module-build and
perl-extutils-cbuilder are in core perl now so are no longer required in
makedepends.  You may still need perl-yaml though.

Have fun,

k


> The extension stuff is twice cause some modules create some man pages
> during the first make and the rest during install, dumb.
> 
> I've already mass converted (hopefully) all of the module PKGBUILDs in
> extra using some sed hacking - I'm just going through them all checking
> for errors and rebuilding.  Technically only modules with *.so libraries
> need to be rebuilt right away to fix the perl symbol problems - pure
> perl modules should be fine for now since the old current directories
> are included in @INC.
> 
> Another thing to note is that additional modules were added to the
> default perl library so some official packages are not needed once
> 5.10.0 is installed.  However the packages can be used to "update" parts
> of the perl library.  I'm not sure how we're going to deal with this
> situation yet.  For example perl 5.10.0 now comes with
> IO::Compress::Base version 2.008, perl-io-compress-base is 2.006.  The
> package is not required until 2.009 is released and before the perl
> package gets updated.
> 
> k
> 
> 
-- 
K. Piche <kpiche at rogers.com>





More information about the arch-dev-public mailing list