[aur-general] perl 5.10.0 coming soon
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
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
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
On Tue, Mar 18, 2008 at 3:50 PM, Firmicus <Firmicus@gmx.net> 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
Abhishek Dasgupta a écrit :
On Tue, Mar 18, 2008 at 3:50 PM, Firmicus <Firmicus@gmx.net> 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
My remark above only applied to the PKGBUILDs I have prepared for sergej, allan and bardo. In general all perl packages should be rebuilt when perl 5.10 leaves testing, especially those that include compiled libraries (such as for example perl-fcgi or perl-gtk2-trayicon). Maintainers of such packages in AUR/unsupported should also update their PKGBUILDs (using the template I provided yesterday). F
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
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
Well, it turns out I maintain all but the last one of the above :D perl-time-piece is in unsupported (version 1.11 vs 1.12 in core perl), so it can be removed from AUR.
On Mon, Mar 17, 2008 at 11:27 PM, Firmicus <Firmicus@gmx.net> 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
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?
2008/3/19, Firmicus <Firmicus@gmx.net>:
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 (Роман Кирилич)
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.
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 <Firmicus@gmx.net> 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.
Since we are rebuilding our perl pkgs anyway, I thought we might as well standardize the names of those few which are still not standard. (The naming convention is this: if a CPAN distribution is obtained from the tarball Foo-Bar-0.1.2.tar.gz then our package should be named perl-foo-bar.) Sergej, could you please rename those two packages you have inherited from xterminus? perl-io-gzip -> perlio-gzip (no pkgs in community depend on it AFAICS) perl-libxml and perl-libxml-common -> perl-xml-libxml and perl-xml-libxml-common (perl-xml-atom and perl-xml-libxslt depend on perl-libxml, so be sure to change the depends array for the former, and I'll take care of the latter. You should also inform the maintainers of the packages xmltv and shownews, which also depend on perl-libxml). Best, F
participants (6)
-
Abhishek Dasgupta
-
Allan McRae
-
bardo
-
Firmicus
-
Georg Grabler
-
Roman Kyrylych