On Jan 2, 2008 1:34 AM, Jason Chu wrote:

On Tue, Jan 01, 2008 at 12:16:19PM -0500, K. Piche wrote:

...

I put perl 5.10.0 in testing. It follows the new perl hierarchy, the install file removes the symlink farm that confused everybody and it prints a small blurb about the update.

Please test,

As mentioned by Pierre I ran into the ptar and ptardiff conflicts. I ended up just forcing the upgrade (probably not the best idea in the long run though).

I'm also having a problem starting spamassassin with this version. It might not be the fault of perl, but here's the error message anyway:

:: Stopping spamd [DONE] :: Starting spamd [BUSY] /usr/bin/perl: symbol lookup error: /usr/lib/perl5/site_perl/current/i686-linux-thread-multi/auto/HTML/Parser/Parser.so: undefined symbol: Perl_Tstack_sp_ptr [FAIL]

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

On Jan 2, 2008 8:10 PM, K. Piche 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

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 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

On Tue, 2008-01-08 at 14:43 +0200, Roman Kyrylych wrote:

2008/1/3, K. Piche :

...

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.

I'm confused. If perl-io-compress-base will be at 2.009 and perl package will still have 2.008 - user cannot install perl-io-compress-base because pacman will complain about file conflicts. Either perl package should be rebuilt to include the newer IO::Compress::Base or all those base modules can be deps (or cannot because of tech limitations?). Did I get this right? (I'm not a perl user, never got to writing anything in it after reading some book long ago :-P)

It's magic grasshopper! The new perl policy allows for perl module packages to take precedence over the standard modules included in the perl package. The standard perl modules live in /usr/{lib,share}/perl5/core_perl and the module packages live in /usr/{lib,share}/perl5/vendor_perl. Also the user can install modules using the CPAN tool and those go in /usr/{lib,share}/perl5/site_perl. There can be three different versions of a perl module co-existing without file conflicts (well except for man pages, shh!). It's basically like the $PATH variable but in perl it's called @INC. So when I say "updated" I mean that a package or CPAN-installed module are in the PATH before the perl package's modules. Hope that made sense. k -- K. Piche

-----Oorspronkelijk bericht----- Van: arch-dev-public-bounces@archlinux.org [mailto:arch-dev-public- bounces@archlinux.org] Namens K. Piche Verzonden: woensdag 9 januari 2008 5:27 Aan: Public mailing list for ArchLinux development Onderwerp: Re: [arch-dev-public] Updated perl 5.10.0

There can be three different versions of a perl module co-existing without file conflicts (well except for man pages, shh!). It's basically like the $PATH variable but in perl it's called @INC. So when I say "updated" I mean that a package or CPAN-installed module are in the PATH before the perl package's modules.

Hope that made sense.

In the ideal world we would have versioned conficts and replaces options available in PKGBUILD. This means that perl with an included package can replace an installed perl package which is below or at the version included in perl. Maybe something for pacman 3.2?

-----Oorspronkelijk bericht----- Van: arch-dev-public-bounces@archlinux.org [mailto:arch-dev-public- bounces@archlinux.org] Namens Roman Kyrylych Verzonden: woensdag 9 januari 2008 13:07 Aan: Public mailing list for ArchLinux development Onderwerp: Re: [arch-dev-public] Updated perl 5.10.0

2008/1/9, Jan de Groot : ideal world we would have versioned conficts and replaces options

...

available in PKGBUILD. This means that perl with an included package can replace an installed perl package which is below or at the version included in perl.

Maybe something for pacman 3.2?

Heh, faster! ;-) A quote from Pacman 3.1 NEWS file: - versioned provisions support - versioned conflicts support - add < and > operators for versioned dependencies and conflicts

Doesn't mention replaces though ;)

On Jan 2, 2008 8:10 PM, K. Piche wrote:

On Wed, 2008-01-02 at 07:11 -0600, Dan McGee wrote:

...

On Jan 2, 2008 1:34 AM, Jason Chu wrote:

...

On Tue, Jan 01, 2008 at 12:16:19PM -0500, K. Piche wrote:

...

I put perl 5.10.0 in testing. It follows the new perl hierarchy, the install file removes the symlink farm that confused everybody and it prints a small blurb about the update.

Please test,

As mentioned by Pierre I ran into the ptar and ptardiff conflicts. I ended up just forcing the upgrade (probably not the best idea in the long run though).

What's the conflicting package? I've never seen a conflict.

perl-archive-tar (required by spamassassin) I'd venture a guess that it's not needed anymore? Maybe rebuild spamassassin without the dep and/or add a conflicts/provides to the new perl package?