cpan2pkg is the tool used to automatically package a module from cpan to mageia as a rpm, along with all its dependencies. it's built on shoulders of giants (cpan2dist, mgarepo, poe, etc)
it used to feature a tk window with one tab per module being investigated - but this was troublesome for people wanting to have a cli. so i just released a new version of cpan2pkg which brings a --text flag (or -T for the lazy ones) which works on the tty. of course, we loose the ability to interact with the application, but that's still convenient sometimes. and of course, the tk version is still available!
Showing posts with label cpan. Show all posts
Showing posts with label cpan. Show all posts
2012-09-25
2012-07-12
more than 3000 perl packages in mageia!
long time no post... but now that mageia perl stats are up & running (daily update), i can as well present the site and brag about the new record we achieved: mageia is now shipping with more than 3000 perl packages, for a total of 26500+ real perl modules. not that bad, uh? :-)
2011-11-24
audio::mpd gained ipv6 support
when i got a bug report asking for ipv6 support in audio::mpd, i didn't know where to start, and put it aside... but since i fixed quite a few test bugs in audio-mpd, i thought i could give a try at supporting ipv6.
and it proved quite easy in fact, with io::socket::ip which is a drop-in replacement for io::socket::inet... and thus, by changing 3 strings in audio-mpd, it is now ipv6 enabled - neat!
so, enable ipv6 on your software with the following one-liner:
and it proved quite easy in fact, with io::socket::ip which is a drop-in replacement for io::socket::inet... and thus, by changing 3 strings in audio-mpd, it is now ipv6 enabled - neat!
so, enable ipv6 on your software with the following one-liner:
easy, uh? who said ipv6 was difficult? :-)$ ack -l 'IO::Socket::INET' | xargs perl -pi -E 's/IO::Socket::INET/IO::Socket::IP/g'
2011-09-16
prisk gains its own map format, allowing translations!
till now, games::risk was using map files from jrisk. this allowed me to concentrate on the gui and the game experience without having to tackle everything at once.
being a simple format, it was somehow easy to read the maps... but its simplicity has some drawbacks, and for example it's not possible to translate them. therefore, i finally bit the bullet and implemented a format for prisk. basically, information remains the same (such as the mechanism to determine the current country), with one exception: maps are implemented as perl modules. and this allows the use of gettext and other i18n schemes.
this means that maps are now translatable! french translation is of course provided, but help is needed for other languages... (hint, hint)
of course, i wrote an importer to migrate jrisk maps to new prisk format. i also intend to take this opportunity to create some new perl dists with extra maps.
this prisk release shows also a lot of cleanup in the internals, with a partial migration to moose and moosex::poe. using weak_ref for scalar attributes and a tied hash::noref to cache objects allowed to use circular references without having to deal with their problems. finally, prisk is now deferring some module loading to runtime, leading to a faster startup. the changes are plenty, so now is a good time to give it a try! (after v3.112590 has hit your nearest mirror of course)
future releases will continue to see code cleanups and migration to moose. prisk also finally has a configuration system to save user preferences - i "just" need to use this system throughout the code. some dialogs needs also to migrate to prisk's look&feel (thanks tk::role::dialog), and i have some ideas to improve the artificial intelligences & better use poe. not counting other game modes to take into account... oh well, let's say that prisk will keep me busy quite some time! :-)
being a simple format, it was somehow easy to read the maps... but its simplicity has some drawbacks, and for example it's not possible to translate them. therefore, i finally bit the bullet and implemented a format for prisk. basically, information remains the same (such as the mechanism to determine the current country), with one exception: maps are implemented as perl modules. and this allows the use of gettext and other i18n schemes.
this means that maps are now translatable! french translation is of course provided, but help is needed for other languages... (hint, hint)
of course, i wrote an importer to migrate jrisk maps to new prisk format. i also intend to take this opportunity to create some new perl dists with extra maps.
this prisk release shows also a lot of cleanup in the internals, with a partial migration to moose and moosex::poe. using weak_ref for scalar attributes and a tied hash::noref to cache objects allowed to use circular references without having to deal with their problems. finally, prisk is now deferring some module loading to runtime, leading to a faster startup. the changes are plenty, so now is a good time to give it a try! (after v3.112590 has hit your nearest mirror of course)
future releases will continue to see code cleanups and migration to moose. prisk also finally has a configuration system to save user preferences - i "just" need to use this system throughout the code. some dialogs needs also to migrate to prisk's look&feel (thanks tk::role::dialog), and i have some ideas to improve the artificial intelligences & better use poe. not counting other game modes to take into account... oh well, let's say that prisk will keep me busy quite some time! :-)
2011-08-29
the great renaming: Dist::Zilla::Plugin::CriticTests
oops! kentnl did it again. :-)
this time, dist::zilla::plugin::critictests has been renamed to dist::zilla::plugin::test::perl::critic. once again, change will be trivial for authors [0]. previous module will continue working, for at least one year counting from today.
github repository has also changed and is available here: https://github.com/jquelin/dist-zilla-plugin-test-perl-critic
[0] and this time, i did not fubar-ed the code! :-|
this time, dist::zilla::plugin::critictests has been renamed to dist::zilla::plugin::test::perl::critic. once again, change will be trivial for authors [0]. previous module will continue working, for at least one year counting from today.
github repository has also changed and is available here: https://github.com/jquelin/dist-zilla-plugin-test-perl-critic
[0] and this time, i did not fubar-ed the code! :-|
2011-08-27
the great renaming: Dist::Zilla::Plugin::CompileTests
in a move to rationalize the plugin namespace of dist::zilla, kentnl started a great renaming: dzp:compiletests has been renamed to dzp:test::compile
previous module is deprecated, and may be removed later on (but not before one year, that is 2012-08-27). in the meantime, it will continue working (although with a warning).
what does it mean for dzil users? well, nothing much, since old module will continue working as is. however, they should better migrate their dist.ini from:
nothing else is needed... for now, since i guess kentnl will continue proposing patches / pullreqs to dzil:*tests plugin authors! ;-)
also, please note that the github repository has been renamed and is now available at a different url. ditto for cpan, since the dist is now named dist-zilla-plugin-test-compile.
previous module is deprecated, and may be removed later on (but not before one year, that is 2012-08-27). in the meantime, it will continue working (although with a warning).
what does it mean for dzil users? well, nothing much, since old module will continue working as is. however, they should better migrate their dist.ini from:
to:[CompileTests]
[Test::Compile]
nothing else is needed... for now, since i guess kentnl will continue proposing patches / pullreqs to dzil:*tests plugin authors! ;-)
also, please note that the github repository has been renamed and is now available at a different url. ditto for cpan, since the dist is now named dist-zilla-plugin-test-compile.
2011-06-27
cpan2pkg: prettier gui, ready for mageia!
remember cpan2pkg? this is the tool built around cpan2dist to create a native linux package, taking dependencies into account, and integrated with linux distribution repository + buildsystem.
it used to be mandriva only, and curses-based. now that mageia is in full swing mode, i had to port cpan2pkg to support it. and it was a perfect opportunity to clean up the module, and prettify the interface.
here's the result:
on the left, you can see the modules currently being processed, with their status both locally and on the build-system. green means available, and here you can see that moosex::alwayscoerece is being built locally (orange) and is not yet available on mageia (yellow).
note that mageia is fully supported: cpan2pkg will poll the buildsystem status page to follow a module build, and make sure a module is ready before submitting those depending on it.
it is still using poe underneath, but this time with tk. adding support for a platform can be done quite easily - patches welcome!
it used to be mandriva only, and curses-based. now that mageia is in full swing mode, i had to port cpan2pkg to support it. and it was a perfect opportunity to clean up the module, and prettify the interface.
here's the result:
on the left, you can see the modules currently being processed, with their status both locally and on the build-system. green means available, and here you can see that moosex::alwayscoerece is being built locally (orange) and is not yet available on mageia (yellow).
note that mageia is fully supported: cpan2pkg will poll the buildsystem status page to follow a module build, and make sure a module is ready before submitting those depending on it.
it is still using poe underneath, but this time with tk. adding support for a platform can be done quite easily - patches welcome!
2011-04-12
a bit of dwimery in magpie
all the pieces were available, binding them together was just a smop. therefore magpie just got a new subcommand: "magpie dwim" which does exactly what i mean...
in the case of magpie, what i mean is of course:
you too can have some fun:
maintaining the ~2500 perl module rpm packages in mageia has never been so easy!
in the case of magpie, what i mean is of course:
- check which perl packages are not up to date wrt cpan
- check them out
- tighten spec file
- update the package to latest version
- commit result
- wait for build system if needed
- submit result
you too can have some fun:
$ sudo urpmi magpie $ magpie dwim
maintaining the ~2500 perl module rpm packages in mageia has never been so easy!
2011-02-28
svk cannot be built anymore - EDIT: svk will build with reduced features
while rebuilding perl packages for mageia, i found out that svn::mirror cannot be built anymore with subversion 1.6.x. said like this, one may think "wtf, i don't give a damn to svn::mirror". and lots of other cpan modules are bit-rotting, so what's the point? well, the thing is, svn::mirror is a prereq for svk, the decentralized subversion...
granted, svk has been end-of-lifed in 2009, yet it's still widely in use. but as long as svn-mirror won't get fixed, mageia won't include svk support.
EDIT (20110301): in fact, svn::mirror is an optional prereq for svk - mageia will therefore ship with svk, albeit with a reduced feature set
granted, svk has been end-of-lifed in 2009, yet it's still widely in use. but as long as svn-mirror won't get fixed, mageia won't include svk support.
EDIT (20110301): in fact, svn::mirror is an optional prereq for svk - mageia will therefore ship with svk, albeit with a reduced feature set
2011-02-10
new magpie command: update
i'm happy to report yet another magpie release, version 1.110410
this release brings a new subcommand: update (aka refresh)
it will automatically update a perl module package being checked out to the latest version, update buildrequires (with fixspec), try to build it locally, commit if successful, wait according to build-system hints, then submit it.
it's easy to use:
note: it requires a minicpan installation on your computer...
now, you too can join the fun of updating perl modules packages for mageia! but it's not yet over, automation will go one step further - stay tuned...
this release brings a new subcommand: update (aka refresh)
it will automatically update a perl module package being checked out to the latest version, update buildrequires (with fixspec), try to build it locally, commit if successful, wait according to build-system hints, then submit it.
it's easy to use:
$ eval $( magpie co -s perl-Foo-Bar )
$ magpie update -v
note: it requires a minicpan installation on your computer...
now, you too can join the fun of updating perl modules packages for mageia! but it's not yet over, automation will go one step further - stay tuned...
2011-02-03
new dist::zilla command: pot
i just released dist::zilla::app::command::pot, providing dist::zilla with a new pot command (not the plant, you hippy!).
this command allows to (re-)generate a messages.pot file holding all strings to be translated from your module. If a messages.pot file is found, it will update it. otherwise, you will be prompted for a file location, with a default matching Locale::TextDomain settings:
this command allows to (re-)generate a messages.pot file holding all strings to be translated from your module. If a messages.pot file is found, it will update it. otherwise, you will be prompted for a file location, with a default matching Locale::TextDomain settings:
$dzil potyup, underneath it just runs xgettext. and currently, it only finds calls to T() - but i'll add an option to provide your own convention such as _(), gettext(), etc.
[...]
[DZ] Trying to find a messages.pot file...
[DZ] No messages.pot found - enter your own.
messages.pot to use [lib/LocaleData/Foo-Bar-messages.pot]:
[DZ] Running xgettext...
2010-06-08
how to retrieve image size in perl
today's topic is quite easy: retrieving image size (in perl, with the help of cpan of course). indeed, when one wants to resize an image, it's often interesting to know its current size.
the easiest way to retrieve those information is of course to use image::size:
easy, wasn't it?
however, as mentioned previously, retrieving those information is often just the prelude before doing some transformation to the image itself. and image::size, while doing it perfectly, does only one thing - it cannot be used for any other image manipulation. so if you intend to use another module after, you can as well use this other module to retrieve this information: that'll be faster (image read only once) and use less memory (only one module loaded). here's how to get those information with image::magick:
it wasn't that difficult, and opens the whole image magick world to your program!
the easiest way to retrieve those information is of course to use image::size:
easy, wasn't it?
however, as mentioned previously, retrieving those information is often just the prelude before doing some transformation to the image itself. and image::size, while doing it perfectly, does only one thing - it cannot be used for any other image manipulation. so if you intend to use another module after, you can as well use this other module to retrieve this information: that'll be faster (image read only once) and use less memory (only one module loaded). here's how to get those information with image::magick:
it wasn't that difficult, and opens the whole image magick world to your program!
2010-03-31
dzil activity
of course, you are aware that dzil v2 is out, with lots of exciting new features, brought to you by rjbs and the perl foundation.
but it's only one side of the activity floating around dist-zilla... indeed, as dagolden, aevar and others try dzil, they (of course) like it, and start contributing their own plugins.
here's a list of new plugins landed on cpan... first some additional author tests:
some plugins to complete meta-data:
some plugins to generate additional files:
some plugins to compute your next version number:
and finally some bundles:
you can install all of them in one go via task-dist-zilla.
they are also available in mandriva, and suggested when installing dist-zilla...
but it's only one side of the activity floating around dist-zilla... indeed, as dagolden, aevar and others try dzil, they (of course) like it, and start contributing their own plugins.
here's a list of new plugins landed on cpan... first some additional author tests:
- CheckChangesTests - check changelog
- CheckExtraTests - runs xt/ tests, but don't copy them to t/
- DistManifestTests - check manifest
- HasVersionTests - check all your modules have a version
- KwaliteeTests - check your kwalitee
- MinimumVersionTests - check minimum perl version needed
- PodSpellingTests - check pod spelling
- PortabilityTests - check if your code is portable
- SynopsisTests - check if code in your synopsis compiles
- UnusedVarsTests - detects unused vars
- ReportVersions - additional test to report version
some plugins to complete meta-data:
- Bugtracker - http://rt.cpan.org/Public/Dist/Display.html?Name=xxxx
- HomePage - http://search.cpan.org/dist/xxxx
- ModuleBuild::Custom - for mb
- OverridableMakeMaker - for eumm
some plugins to generate additional files:
- FatPacker - creates a script with all dependencies packed
- InstallGuide - creates an INSTALL file
- ReadmeMarkdownFromPod - README.mkdn file
some plugins to compute your next version number:
- BumpVersionFromGit - version taken from last git tag
- VersionFromPrev - classic perl versions, 1.00 to 1.99
and finally some bundles:
you can install all of them in one go via task-dist-zilla.
they are also available in mandriva, and suggested when installing dist-zilla...
2010-03-23
how to obsolete a cpan dist?
my autoprereq plugin for dist-zilla is now going core. however, it's currently existing as a dist of its own within cpan... since the module does not change name, what is needed to make sure rjbs can upload dzil v2 when it's ready? is giving co-maint rights on pause enough? will i have to remove previous tarballs?
the same kind of question can be asked for obsoleting a given module. there's (afaik) no way to tell cpan / cpanplus that foo::bar is replacing bar::foo... those problems are tackled for linux distribution packages, could we reuse some of their logic here?
the same kind of question can be asked for obsoleting a given module. there's (afaik) no way to tell cpan / cpanplus that foo::bar is replacing bar::foo... those problems are tackled for linux distribution packages, could we reuse some of their logic here?
2010-01-27
stats about cpan modules shipped by mandriva
adam and gabor asked me about some information on what cpan modules are shipped as rpm packages by mandriva... i finally found some time to work on it and produced ordb::cpan::mandriva.
this module is basically a sqlite database replicated automatically by orlite::mirror. using it is very simple - for example, couting the cpan dists shipped by mandriva is achieved by the following snippet:
(fyi, the result is 1899 as of writing, +1 since i just imported the module itself)
at module use time, it will automatically download (and cache for a week) the sqlite database. and one can then use the module as an ordb for this db... the module does not however produces the stats for you - so alias & gabor, now is your turn to work! :-) i'm waiting for your top-100 most wanted mandriva or whatever crazy stats you'll want to produce.
the database itself is generated by module::packaged::generator. this module uses different drivers depending on the current linux distribution (but nothing prevents *bsd to also have a driver) it runs on. only mandriva is supported currently, but ryan will work on a debian driver. all other contributions are most welcome - the code is on github: fork it and send me pull requests!
this module is basically a sqlite database replicated automatically by orlite::mirror. using it is very simple - for example, couting the cpan dists shipped by mandriva is achieved by the following snippet:
(fyi, the result is 1899 as of writing, +1 since i just imported the module itself)
at module use time, it will automatically download (and cache for a week) the sqlite database. and one can then use the module as an ordb for this db... the module does not however produces the stats for you - so alias & gabor, now is your turn to work! :-) i'm waiting for your top-100 most wanted mandriva or whatever crazy stats you'll want to produce.
the database itself is generated by module::packaged::generator. this module uses different drivers depending on the current linux distribution (but nothing prevents *bsd to also have a driver) it runs on. only mandriva is supported currently, but ryan will work on a debian driver. all other contributions are most welcome - the code is on github: fork it and send me pull requests!
2010-01-07
cpan task for dist-zilla
dist-zilla has a lot of prereqs. and even when you have installed it, you may need to install other plugins manually. therefore, i just uploaded task::dist::zilla that pulls in all dzil plugins and plugin bundles.
it still takes time to install all those modules, but at least you can do it in one go with cpan or cpanplus: no need to install them one by one manually.
of course, if you're on mandriva, running:
it still takes time to install all those modules, but at least you can do it in one go with cpan or cpanplus: no need to install them one by one manually.
of course, if you're on mandriva, running:
will install the package perl-Dist-Zilla and all its deps while also suggesting to install all the dzil plugins...urpmi perl-Dist-Zilla
2010-01-04
retrospective 2009
2009's over, but the year was quite a busy one for me on the perl front:
- i finally took the time to investigate moose, and decided to port some of my code to use it.
- i discovered dist::zilla, and definitely plan to use it in all my dists.
- i discovered some other cool new perl modules (thanks guys).
- i uploaded some new dists on cpan, including games::pandemic (which i'm quite proud of, even if i need to continue hacking on it).
- i updated & released some of my existing dists.
- i contributed to other projects such as padre, dist-zilla, etc. sending patches is a good way to thank the author for their work.
- it's even easier to contribute with github, which i'm using more and more for my projects (and it's no more slow by now, woohoo!). of course, git is the master piece allowing this easy sharing.
- on mandriva's front, i resurrected parrot rpm, and finally shipped rakudo.
- 2009 was also the year of the great migration to %perl_convert_version
- ... with lots of new perl modules available as rpm (i am managing 450 of them).
- ... and finally i took ownership of perl rpm. (thank you perl5 porters btw for 5.10.1 and the push for next stable version!)
2009-12-29
helping perl packagers package perl modules (for real this time)
chromatic posted a long rant (who would have guessed? :-) ) about perl modules shipped by linux distributions. however, he doesn't have all the answers... nor the experience needed for this rant. since i'm a perl author and mandriva packager for perl and lots of perl modules, i think i have more enlightened information about this topic.
first, let me state that using system perl is fine, but i really discourage it for your enterprise application. the perl version will change from time to time, ditto for the perl modules you are relying upon. so if you want to be in control your software foundation for your app (and you should) - compile your perl and your modules yourself.
second thing: i also discourage mixing using perl modules installed by your package system and by running cpan as root. you'll end up with a mix of files in /usr/perl5 that either belong or not to a system package, which sucks. installing packages in a local lib of yours is fine, which is made quite easy with local::lib by now.
if you're comfortable with those rules, then you're welcome to using the system perl and the modules shipped by your distribution. after all, we packagers are going through this work in the hope of being useful to others - that is, you!
but back to chromatic post. if you want to install cpan modules as system packages, there's already a tool that does it for you: it's called cpan2dist, and is part of cpanplus. it works as long as a backend for your distribution exists. there's currently one for debian, mandriva (that i wrote), fedora and gentoo. it's not that difficult to write, and allows you to write:
however, if you want to help perl packagers package your modules for a distribution, here's a list of thing that you should not do. this is a list of real, practical things to do as a module author - not some generic hand-waving towards the perl community out there. this comes from my experience as packager for mandriva of more than 400 modules, and makes me curse the module author everytime i'm encountering one of those problems...
if you're following all those advices, packagers of your modules will love you. (or at least, not hate you - which is still a win :-) ). i know i will...
first, let me state that using system perl is fine, but i really discourage it for your enterprise application. the perl version will change from time to time, ditto for the perl modules you are relying upon. so if you want to be in control your software foundation for your app (and you should) - compile your perl and your modules yourself.
second thing: i also discourage mixing using perl modules installed by your package system and by running cpan as root. you'll end up with a mix of files in /usr/perl5 that either belong or not to a system package, which sucks. installing packages in a local lib of yours is fine, which is made quite easy with local::lib by now.
if you're comfortable with those rules, then you're welcome to using the system perl and the modules shipped by your distribution. after all, we packagers are going through this work in the hope of being useful to others - that is, you!
but back to chromatic post. if you want to install cpan modules as system packages, there's already a tool that does it for you: it's called cpan2dist, and is part of cpanplus. it works as long as a backend for your distribution exists. there's currently one for debian, mandriva (that i wrote), fedora and gentoo. it's not that difficult to write, and allows you to write:
this will automatically download foo::bar, check its dependencies (and build & install them if needed recursively), build the module as a mandriva package and install it. what else exactly do you want/need? (as a cpanplus backend writer, i do have some things that i'd like cpan2dist to have, but none as a regular user). and if you're a packager and want to integrate cpan2dist with your linux distribution build system, cpan2pkg can help you (even if it's currently stalled due to sthg missing in cpanplus).# cpan2dist --format CPANPLUS::Dist::Mdv --install Foo::Bar
however, if you want to help perl packagers package your modules for a distribution, here's a list of thing that you should not do. this is a list of real, practical things to do as a module author - not some generic hand-waving towards the perl community out there. this comes from my experience as packager for mandriva of more than 400 modules, and makes me curse the module author everytime i'm encountering one of those problems...
- test your dist before shipping. really, i'm not kidding. lots of dists just fail their tests. and not just on linux, on all the platforms. so if you make an update that "just can't fail" (yeah, right) to your dist just before shipping, please run your test suite nevertheless. just in case, you know, it might fail.
- if you're shipping pod tests that are skipped depending on the presence of test::pod and test::pod::coverage, make sure you have those modules installed, so you are running those tests, too. even better: skip those tests unless RELEASE_TESTING or AUTHOR_TESTING is set. after all, it's nice for you to know you still have some documentation work to do, but i don't care as a packager... and, you know, it's now the standard & recommended way of shipping those tests.
- those 2 items lead me to another easy thing for module authors to do to help us: check the cpantester status of your dist. investigate all the fails that you have. if you see a fail that is your fault, fix it and upload a new version. it helps us because this prevents us from having to report a bug against your dist. i generally wait 3 or 4 days before reporting a bug on a dist that has some failure reports, hoping (what a fool) that the author will notice by herself that sthg is going wrong.
- speaking of bug reports, if we take the time to open a report for your dist (very often with a patch attached)... please read it. and act. or at least answer us. either apply the patch, or explain why you don't want to apply it like that... and ship a new version of your dist, with the fix included.
- but of course, before reporting a bug, we should find the bug tracker. so, by using rt.cpan.org, you really help us to have a single unified point of contact. i know that rt is kind of slow, not very intuitive, has some problems and could be cleaned out a bit... but it is here, bestpractical is providing & administering it for us for free, and has this nice feature of having a queue for every perl dist on cpan. if you don't want to use it, there are some more polite ways of saying it... and giving the url of your tracker helps, too. oh, and if i took the pain to play by your rules and report a bug to your non-standard bug tracker, i would greatly appreciate that you act on my ticket. or at least, you know, just acknowledge the fact that you received the report.
- if you want to really piss off a packager, a simple but effective way is to change your versioning scheme every now and then, by (ab-)using your knowledge of perl way of understanding versions. in the same major version, of course. going from version 1.470 to 1.50 is not funny. if you want to change your versioning scheme, you can change the major number to. after all, i'm pretty sure that you're not paying any extra money per major number used in your dist. this is what caused us to mangle the version of perl modules shipped in mandriva.
- speaking of regular changes, it's irritating to have to follow you through your use of makefile.pl to build.pl to makefile.pl to build.pl to... well, you understand what i mean. even to use this shiny replacement that is module::build, or this oh-so-marvelous module::install, oh no finally module::build way of working fits me better in retrospective... it's ok for you to change from time to time, but changing at every version of your dist - just make up your mind dammit!
- speaking of it, i hate module::install. and especially its feature that prompts and tries to handle the deps itself coz-it's-so-cool-it-can-do-it-for-real. sorry, but that's not your job in the tool chain. just report that you miss some deps. i know that there's a flag to make this feature go away while launching makefile.pl. but i don't want to bother and would rather expect that the whole stuff has sane defaults...
- oh, and in case you're wondering - every prompting in the configure phase (makefile.pl or build.pl) sucks and should be banned.
- having clear and up-to-date dependencies would be fine, too. i know it's not always easy to have them correctly, but you can change your tools and adopt one that extract your prereqs for you.
- try to avoid dependency on modules that are known to fail. even if it works in your setup, trust cpantesters if they tell you that it fails 95% of its reports: it might not be a good idea to depend on it.
- trying to support old perl versions and old releases of modules is fine, but update your modules and see if your code work. some functions may become deprecated, or you were relying on a buggy behaviour, or whatever. we update the perl packages as we see new versions, not only your modules. so a linux dist will usually have latest & greatest version of all the modules - you'd better be sure that your code work with them, hmm?
- finally, if you're developping under macosx, make sure that you don't ship resource files, or textmate temp files. having ._Foo.pm in the dist is not fun: automatic compile tests will fail, unless that's your manicheck or signature check. and even if everything in perl dist is fine, things may bork in the repackaging of the system package due to a file not listed. so, be extra careful when shipping your dist - or change platform and burn your shiny toy that calls itself a computer (careful & clever readers may have guessed from previous sentence that i don't like macosx - but that's not a reason to ditch this post and not to follow the advices i'm reporting).
if you're following all those advices, packagers of your modules will love you. (or at least, not hate you - which is still a win :-) ). i know i will...
2009-11-09
cpan activity
with mandriva linux 2010.0 out, it's time to have a look at cpan activity once again.
version freeze happened on october 1st for mandriva, at which point it wasn't possible to upload new version - unless to fix a bug preventing usage. since we know that cpan modules don't have such bugs[0], it means that almost no perl package was updated till cooker[1] reopening (which happened on november 6th).
so, how many dists needed an update after ~40 days? around 150. yes, 150. on 1685 distributions shipped by mandriva. and some of those were updated more than once...
that's ~10%. a bit less than what was reported in april for mandriva 2009.1, but:
[0] :-)
[1] cooker is mandriva's development version
version freeze happened on october 1st for mandriva, at which point it wasn't possible to upload new version - unless to fix a bug preventing usage. since we know that cpan modules don't have such bugs[0], it means that almost no perl package was updated till cooker[1] reopening (which happened on november 6th).
so, how many dists needed an update after ~40 days? around 150. yes, 150. on 1685 distributions shipped by mandriva. and some of those were updated more than once...
that's ~10%. a bit less than what was reported in april for mandriva 2009.1, but:
- this time it's for whole mandriva, not only the packages i'm responsible for
- freeze was a bit longer for 2009.1
[0] :-)
[1] cooker is mandriva's development version
2009-11-03
the state of perl in mandriva 2010
mandriva linux 2010 is out... this is thus a good time to have a look at the state of perl in this release.
adelie (mdv 2010 codename) ships perl 5.10.1 with threads[0], which allowed me to drop half the patches carried within mandriva[1]. and since perl 5 porters hope to make perl 5 releases more often, it means that (hopefully) i'll be able to trim down those patches even more!
on the modules front, mandriva is shipping plenty of them. padre 0.47 (and lots of plugins), moose, poe framework (and lots of components), devel modules, dbi drivers, gui (tk, wx, gtk) and various lib bindings, you name it... using book's pearl of wisdom, this gives us[2]:
but the biggest change that you will see in mandriva 2010 regarding perl (well, maybe you won't even notice it), is the new standardized version scheme forced upon all perl modules. for example, dist-zilla version 1.092680 is shipped for mandriva 2010 in rpm perl-Dist-Zilla-1.92.680. yes, i know, it means that the mandriva version might differ from upstream version. yes, i am aware that this sucks. yes, i am also aware that there's no real way to get upstream version back from mandriva rpm version. and no, i don't plan to roll back this change - unless you have another miracle solution that deals with rpm not understanding cpan modules changing their versioning scheme without bumping their major (grrr!).
however, note that previous mandriva version (and fedora too) already mangled some modules version, but not all of them - which is even worse imo. since i agree with david that version numbers should be boring, all modules now have their version mangled. no ifs, no buts, we're mangling it. and it makes life easier for us packagers...
of course, the modules' code is not affected by this change. it's only the packaging that changed a bit. to check which version is installed, just check the $VERSION of this package. that's always been, and remains, the only safe way to be sure. eg:
all in all, that's a quite a good release on the perl front. if you add all the work that went in all other areas, mandriva 2010 will be quite a solid release. i invite you to test it out - who knows, you might even like it so much that you'll switch to it permanently! :-)
[0] no need to complain, rgs - i know your feelings about it.
[1] yup, i took the ownership of the perl package - silly me...
[2] why, yes, i install all perl modules available as rpm on my box :-)
adelie (mdv 2010 codename) ships perl 5.10.1 with threads[0], which allowed me to drop half the patches carried within mandriva[1]. and since perl 5 porters hope to make perl 5 releases more often, it means that (hopefully) i'll be able to trim down those patches even more!
on the modules front, mandriva is shipping plenty of them. padre 0.47 (and lots of plugins), moose, poe framework (and lots of components), devel modules, dbi drivers, gui (tk, wx, gtk) and various lib bindings, you name it... using book's pearl of wisdom, this gives us[2]:
that's not half of cpan, but a good deal nevertheless. chances are that you will find the module you need - and if you don't, drop me a mail or open a request and i'll package it for you.12117 installed modules
including 11016 from cpan (15.65% of cpan)
that is 1685 distributions (8.88% of cpan)
but the biggest change that you will see in mandriva 2010 regarding perl (well, maybe you won't even notice it), is the new standardized version scheme forced upon all perl modules. for example, dist-zilla version 1.092680 is shipped for mandriva 2010 in rpm perl-Dist-Zilla-1.92.680. yes, i know, it means that the mandriva version might differ from upstream version. yes, i am aware that this sucks. yes, i am also aware that there's no real way to get upstream version back from mandriva rpm version. and no, i don't plan to roll back this change - unless you have another miracle solution that deals with rpm not understanding cpan modules changing their versioning scheme without bumping their major (grrr!).
however, note that previous mandriva version (and fedora too) already mangled some modules version, but not all of them - which is even worse imo. since i agree with david that version numbers should be boring, all modules now have their version mangled. no ifs, no buts, we're mangling it. and it makes life easier for us packagers...
of course, the modules' code is not affected by this change. it's only the packaging that changed a bit. to check which version is installed, just check the $VERSION of this package. that's always been, and remains, the only safe way to be sure. eg:
$ perl -E 'for (@ARGV){eval "require $_"; say "$_\t",$_->VERSION if !$@}' Dist::Zilla
Dist::Zilla 1.092680all in all, that's a quite a good release on the perl front. if you add all the work that went in all other areas, mandriva 2010 will be quite a solid release. i invite you to test it out - who knows, you might even like it so much that you'll switch to it permanently! :-)
[0] no need to complain, rgs - i know your feelings about it.
[1] yup, i took the ownership of the perl package - silly me...
[2] why, yes, i install all perl modules available as rpm on my box :-)
Subscribe to:
Posts (Atom)
