Firmicus wrote:

Hello all,

this message is primarily adressed at the few TUs who maintain perl packages in community (namely Sergej, Allan and bardo), but should also be read by everyone else contributing perl packages to AUR as well.

perl 5.10.0 – currently in testing – will soon be moved to core. Since this release implements a new "Perl Policy", there are some important changes in packaging that should be noted. Also, all packages that provide compiled libraries or that embed their own perl engine must be recompiled. Even better is to update ALL perl packages according to the new path scheme.

See http://ankabut.net/archlinux/perlcommunity/PKGBUILD-perl.proto for the new and simpler way to package perl stuff.

Since I had to do the job for my packages anyway, it was equally easy for me to update all PKGBUILDs at once. So Sergej, Allan and bardo can grab their new PKGBUILDs from

http://ankabut.net/archlinux/perlcommunity/sergej.zip http://ankabut.net/archlinux/perlcommunity/allan.zip http://ankabut.net/archlinux/perlcommunity/bardo.zip

Note that these contain only the packages in lib. There are a few more that I have not touched:

devel/svk devel/perl6-pugs games/hearse multimedia/freewrl multimedia/xmltv network/pppusage

These are left as an exercise to their respective maintainers ;)

Be sure to backup your old PKGBUILDs and to check carefully those I made (especially the depends array). Kevin – the perl maintainer – is going to notify us when he moves perl from testing to core. Then we should get busy building the packages and uploading them to the repo :)

Have fun, Firmicus

Thanks for the PKGBUILDs. Saves me some time over Easter. Allan

On Tue, Mar 18, 2008 at 3:50 PM, Firmicus wrote:

One more thing: I forgot to mention that you should check the pkgrel number and eventually increment it, unless the pkgver has been updated.

F

Does this affect packages utilising Gtk2::Perl too? -- Abhishek

Firmicus a écrit :

Hello all,

this message is primarily adressed at the few TUs who maintain perl packages in community (namely Sergej, Allan and bardo), but should also be read by everyone else contributing perl packages to AUR as well.

perl 5.10.0 – currently in testing – will soon be moved to core. Since this release implements a new "Perl Policy", there are some important changes in packaging that should be noted. Also, all packages that provide compiled libraries or that embed their own perl engine must be recompiled. Even better is to update ALL perl packages according to the new path scheme.

See http://ankabut.net/archlinux/perlcommunity/PKGBUILD-perl.proto for the new and simpler way to package perl stuff.

Since I had to do the job for my packages anyway, it was equally easy for me to update all PKGBUILDs at once. So Sergej, Allan and bardo can grab their new PKGBUILDs from

http://ankabut.net/archlinux/perlcommunity/sergej.zip http://ankabut.net/archlinux/perlcommunity/allan.zip http://ankabut.net/archlinux/perlcommunity/bardo.zip

Note that these contain only the packages in lib. There are a few more that I have not touched:

devel/svk devel/perl6-pugs games/hearse multimedia/freewrl multimedia/xmltv network/pppusage

These are left as an exercise to their respective maintainers ;)

Be sure to backup your old PKGBUILDs and to check carefully those I made (especially the depends array). Kevin – the perl maintainer – is going to notify us when he moves perl from testing to core. Then we should get busy building the packages and uploading them to the repo :)

Have fun, Firmicus

This is again mostly for Sergej, Allan and Bardo (but also of interest to all perl packagers). There's one more thing I forgot to mention ... Perl's new install blurb will show you this: These community packages are also included in the standard perl library: perl-archive-extract perl-cpanplus perl-digest-sha perl-file-fetch perl-extutils-parsexs perl-ipc-cmd perl-locale-maketext-simple perl-log-message perl-log-message-simple perl-module-corelist perl-module-load perl-module-load-conditional perl-module-loaded perl-module-pluggable perl-object-accessor perl-params-check perl-term-ui perl-time-piece which means that if you currently maintain one or more of the above packages, there is no need to update them, as these modules are now part of the core perl library. You can even remove them from community. However, and this is an advantage of the new "Perl Policy", if you feel important to update one of the core modules to a more recent version on CPAN than the one provided with perl, then it is now perfectly possible to do so. Core modules are in the core_perl directories, while those installed by other arch packages go under vendor_perl, which has higher priority. Best, F

On Mon, Mar 17, 2008 at 11:27 PM, Firmicus wrote:

this message is primarily adressed at the few TUs who maintain perl packages in community (namely Sergej, Allan and bardo), but should also be read by everyone else contributing perl packages to AUR as well. [...]

Thank you very much for your work. I actually have a test build on my machine, but I never gave it very much love because I had higher priority tasks to take care of. I've been pretty busy until today, but tomorrow I should (hopefully!) be able to update && test my packages locally. On the other hand, looking at all the critical updates in [testing] in the last weeks, I've been feeling a growing need for a [community-testing] repo. This has been discussed many times, and if I understood correctly there's a serious intention to deploy it, someday. As a TU and Flyspray contributor, all my physical machines run [testing], and I build my [community] packages on a vanilla installation under virtualbox, but as an Arch user my software often breaks and I have to rebuild it by myself. Being the user with the most installed packages (1760) in archstats, you can understand how this is becoming a big task for me. We often have some heavy update under the hood. At the moment, if I don't forget anything, we have three big transitions going on: perl (which has been there for a while, so after the initial shock almost everything is ok), libtool and gcc (but if I got it right it should be a rather "light" update). Being able to test my (and other's) packages with the forthcoming software without having to rebuild the world would be great, and would really boost [community]'s quality, IMHO. Is there any official roadmap to [community-testing]? If the answer is "no, and you'll never see it", then all good for me, I'll find a way to set up one somewhere and encourage current TUs to use it. Corrado

2008/3/19, Firmicus :

...

On the other hand, looking at all the critical updates in [testing] in the last weeks, I've been feeling a growing need for a [community-testing] repo. This has been discussed many times, and if I understood correctly there's a serious intention to deploy it, someday.

<...>

...

Is there any official roadmap to [community-testing]? If the answer is "no, and you'll never see it", then all good for me, I'll find a way to set up one somewhere and encourage current TUs to use it.

Corrado

I am likewise very much in favor of a community-testing repo. Roman, what is the current state of things on this?

Well, technically it could be organized in the same way as testing for core/extra/unstable. But I don't know how AUR backend should be modified for this, because it needs to separate & not mess uploaded packages. I think this would be better implemented with new SCM layout that's pending (for pretty long time already, I'll ping that issue after ISO release) because it will allow such things to be done *much* easier. -- Roman Kyrylych (Роман Кирилич)

Urks.. ouch. Thanks for the advice... need to rebuild some packages, but perl 5.10 comes with some nice features. On Wed, Mar 19, 2008 at 10:34 AM, Firmicus wrote:

...

...

I am likewise very much in favor of a community-testing repo. Roman, what is the current state of things on this?

Well, technically it could be organized in the same way as testing for core/extra/unstable. But I don't know how AUR backend should be modified for this, because it needs to separate & not mess uploaded packages.

I think this would be better implemented with new SCM layout that's pending (for pretty long time already, I'll ping that issue after ISO release) because it will allow such things to be done *much* easier.

That seems to make perfect sense. Please keep us updated on this.