cpan2pkg now available in text mode!

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!

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!

"magpie fix" also tigthens spec files

following cpanplus backend cleaning, "magpie fixspec" also gained the ability to clean up spec files with trivial %clean section and %defattr definition.

this means that updating a perl package on mageia (with either "magpie up" or "magpie dwim") will also trim the rpm spec file accordingly. neat!

more tightened spec file produced by mageia cpanplus backend

cpanplus::dist::mageia 1.111720 has just been released, with 2 changes:

• no more %defattr definition
• no more default %clean section

indeed, rpm will handle those automatically, as dexter mentioned (cf here and here). this way, we'll have spec files a bit more tightened, which is always better from a maintainer pov.

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:

• 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

and all of this is done in parallel, with errors reported at the end.
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!

magpie: how to list non up-to-date perl modules

the final stone is now built for magpie: it's possible to list on your mageia system the perl modules that have up to date versions upstream. it allows to see at a glance which perl packages need to be updated. it's based on cpanplus, and only tackles perl modules installed on your system.

the new command is:

$ magpie old
** core packages: 11

Devel::DProf                             20080331.00 20110228.00
Devel::SelfStubber                              1.03        1.05
[...]
if                                              0.05      0.0601

** normal packages: 57

DateTime::TimeZone                              1.28        1.29     perl-DateTime-TimeZone                                 1.280.0
Digest::SHA                                     5.50        5.60     perl-Digest-SHA                                        5.500.0
[...]
parent                                         0.224       0.225     perl-parent                                            0.224.0

** orphan packages: 7

KENTNL                                      0.010173Dist::Zilla…
[...]
inc::latest                                   0.3624        0.38

** strange packages: 3

App::cpanminus                                1.2001      1.4002     cpanminus(1.200.100),perl-App-cpanminus(1.200.100)
HTTP::Response                                  6.00        6.01     perl-libwww-perl(5.837.0),perl-Test-Mock-LWP(0.50.0),perl-HTTP-Message(6.0.0)
Perl::MinimumVersion                            1.27        1.28     perl-Perl-MinimumVersion(1.270.0),perl-Perl-Critic-Pulp(47.0.0)

** ignored modules: 12

Boulder::Unigene(28051999.00), File::MimeInfo::Rox(0.20), Getopt::Lucid(0.19), HTML::Table(2.08), Imager::Font::Type1(1.011), Inline::Python(0.38), Lingua::Features(0.30), Parse::RecDescent::FAQ::Original(6.00), Switch(2.16), Tie::Watch(1.301), WebFetch(0.13), XML::Grove(0.46)

the columns are: module, old version, new version, mageia package name, mageia package version.

as you can see, the modules are sorted in various categories:

• core - modules shipped with perl (or perl-base)
• dual-lifed (not shown above) - modules that are both shipped with perl (or perl-base) and as a stand-alone package
• normal - regular modules with their own package
• orphan - modules that do not belong to a mageia package (either inherited from mandriva, or not yet pushed on buildsystem).
• strange - modules that belong to more than one magiea package
• ignore - those are modules that either cannot be built (with an upstream bug) or that confuse cpanplus when comparing versions

with this information, it's therefore very straightforward to update the packages, launching the following command as needed:

$ eval $( magpie co -s $pkg ) && magpie update

of course, since all the building blocks are now available, that's what the last command to be implemented (magpie dwim) will do!

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:

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

new magpie command: fixspec

i just released magpie 1.110390, which brings a new subcommand: magpie fixspec

as you can guess, this command will try to sanitize a rpm spec file a bit. to use it, you must be in a package checkout, and run it without any argument.

$ eval $( magpie co perl-Foo-Bar )
$ magpie fixspec -v

# to see the list of options
$ magpie help fix

among the things that fixspec does:

• it updates %doc depending on the existing files, including meta files
• it splits multiple bundled build-/requires to have only one per line
• it lines up vertically the summary / etc
• it extracts perl buildrequires from meta.json/meta.yml if present
• it removes buildroot definition
• it removes mdv macros

note that the code is not really clean, it might gain from being in its
own module, with real rpm parsing instead of big regexes. also, it
assumes that we're cleaning a perl module spec file, so you're on your
own if you're using it on other spec file: it might remove the whole
svn, eat your babies, or even convert your rpm database to rpm5. you've
been warned. :-)

magpie - MAGeia Perl Integration Easy

in my mandriva to mageia switch, i promised to myself that i'd collect the various scripts that i'm using on a day to day basis to maintain the myriad of perl rpm packages.

therefore, i've created magpie (MAGeia Perl Integration Easy) and uploaded it to cpan. the tool is not yet complete, but i'm incorporating new commands now and then.

it currently supports 2 commands:

• magpie bswait - this command pauses according to the recommendation of mageia build-system. it indeed provides some recommendation on how much time to pause between 2 packages submission to not overload it - (this is known as throttling).
• magpie co - this brand new command (in version 1.110320) allows to check-out a given package from mageia repository.

some details about magpie checkout: it is not meant to replace "mgarepo co", it does in fact use mgarepo underneath. so what does this command add?

• the possibility to check out in a given directory
  

  $ magpie co -d ~/rpm/cauldron perl

• the fact that it will either check out *or* update the local check-out if it already exists:
  

  $ magpie co -d ~/rpm/cauldron perl
  # check-out if 1st run, update otherwise

• finally, the possibility to dump a shell command to execute to change directory in the fresh check-out:
  

  # add this in your ~/.bashrc
  function cco() { eval $(magpie co -d ~/rpm/cauldron -q -s $*); }
  # then, one can do a fresh checkout/update + cd by issuing:
  $ cco perl

nothing revolutionary, but it saves some keystrokes here and there.

perl status for mandriva 2010.1 (version freeze)

it's that time of the year: next mandriva version is due beginning of june, which means all updates are on hold - unless they solve a bug or any other problem worth fixing.

on the perl front, mandriva 2010.1 will therefore ship:

• perl 5.10.1 (5.12.x has been postponed to 2011.0)
• padre 0.60
  
• parrot 2.3.0 and rakudo 2010.03
• ... and 1912 dists from cpan!
  

as always, if you miss a perl module, just drop a note (in the comments, or a mail, or on mandriva bugzilla) and i'll package it for you.

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!

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

so, busy indeed 2009 was... i just hope that 2010 will be as fruitful on the perl front for me, and for the perl ecosystem by large.

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:

# cpan2dist --format CPANPLUS::Dist::Mdv --install Foo::Bar

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

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

there, i think that's a pretty good start. i've encountered each and every item of this list at least once (i stopped counting exactly how much a long time ago). don't take it personally if you made some of those mistakes - i have done almost all of them by myself as module author (except of course using module::install and using a mac, but you could have guessed for at least the last part). what's important is to realize that those behaviours are annoying for packagers, and that changing those habits is quite easy to do (except for the burning your mac part, because i agree that it's not very environmental-friendly - see, i'm not that stubborn! ;-) ).

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

rakudo available in mandriva

after some chat with parrot-porters, i finally undertood that what's get installed in /usr/src/parrot (and that i was trimming during installation) is not parrot full source, but intermediate forms of pmc, needed if high-level languages want to subclass them. they are thus now shipped in parrot-src package - and this is enough for rakudo to be compiled.

therefore, rakudo 2009-11 is now (finally) available in mandriva...

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

12117 installed modules
including 11016 from cpan (15.65% of cpan)
that is 1685 distributions (8.88% of cpan)

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.

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

on the parrot front, we're shipping 1.6.0 (1.7.0 was too late to be included). and rakudo is still not present, since it cannot use an installed parrot.

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

mandriva 2010 coming - which perl modules do you miss?

mandriva's next version (2010.0) is now in version freeze, for a release date in early november. this means that current packages are not allowed to be upgraded to latest version, unless there's a compelling reason to do so (security update, crash or big regression).

there is still, however, the possibility to ship new packages. so if you miss some perl modules in mandriva and you really want them available as rpm packages in 2010.0 version, now is the time to speak up! just add your request as comment to this post, and i'll do my best to fulfill it.

perl 5.10.1-rc1 available on mandriva

perl 5.10.1-rc1 has been released 3 days ago, so i packaged it for mandriva. the good thing is that a lot of patches that we were adding to our perl are now merged upstream.

the new perl (perl-5.10.1-0.rc1.2mdv at the time of writing) rpms are available in mandriva testing media. you can install them with:

# urpmi perl perl-base --media "Main Testing"

please report any problem to either mandriva cooker mailing list, or to perl 5 porters if that's a perl related bug.

converting & rebuilding mandriva perl modules rpm

as time went by, the %perl_convert_version^[0] macro in rpm has proven useful to convert perl version number to something that rpm will (should) always be able to parse. i also patched mandriva's perl.prov and perl.req (that automatically extracts requires & provides for perl in rpm packages) to use %perl_convert_version also.

the last step happened this week, when guillomovitch has converted youri checks to also compare newer cpan version with %perl_convert_version. therefore i'm currently migrating the not-yet converted mandriva perl rpm package to use %perl_convert_version also^[1]...

expect some problems during installation till all modules are converted. this should be solved soon.


[0] so that eg 1.54 is understood as 1.540.0, and thus greater than 1.470 - as on cpan.
[1] when the build system works! :-)

which parrot version to package?

after some lengthy discussions finding the final versioning scheme for parrot, allison finally decided that parrot will use the following version numbers:

• 1.0 (March, deprecation point)
• 1.1 (April)
• 1.2 (May)
• 1.3 (June)
• 1.4 (July, deprecation point)
• 1.5 (August)
• 1.6 (September)
• 1.7 (October)
• 1.8 (November)
• 1.9 (December)
• 2.0 (January, deprecation point)
• 2.1 (February)
• 2.2 (March)
• 2.3 (April)
• 2.4 (May)
• 2.5 (June)
• 2.6 (July, deprecation point)
• 2.7 (August)
• 2.8 (September)
• 2.9 (October)
• 2.10 (November)
• 2.11 (December)
• 3.0 (January, deprecation point)

the stable versions will be the deprecation points - that is, 1.0.0, 1.4.0, 2.0.0, 2.6.0 and 3.0.0. this means that those versions may have some bugfix releases during their support lifetime (1 year), but only for very limited stuff (security or other critical problems). everything is described in parrot's support policy.

as parrot packager for mandriva, this is good to know. however, i don't really know what to do: should i package the stable versions? or should i update the package for each new devel version?

since parrot is quite in flux those times, version 1.0.0 (which is 3 monthes old) is really useless... if you add that almost nothing production-ready relies on it currently, i have decided to update the package on a monthly basis. which means that rpm for parrot 1.3.0 is available on cooker right now.

but let's think forward a bit... when rakudo will be able to use an existing parrot, when perl 6 will be in production, i won't continue like that: i'll just stick (of course) with the production releases... but when will this point happen? when will i switch from devel to stable versions? this remains to be seen...

cpan2dist oddity

cpanplus is great - really, i mean it. i don't like its internals, and having to adapt to it for cpanplus::dist::mdv is not my fondest memory. however, it gets the job done, and that's what counts in the end.

but cpanplus has some oddities in the user-space also. cpan2dist, which is a tool allowing you to create a native package for your platform, sometimes makes me cry.

it insists on building prereqs for the module you want. that's fine, except for one thing: it will also build packages for modules that are not up to date... and this is where the fun starts.

you can think that --nobuildprereqs would prevent this, but nope, it's the default and really means: "don't rebuild prereqs if we're at latest version, but rebuild anyway if we're not at latest version". the --buildprereqs indeed means "i really really want to loose my time, please rebuild a package for all the prereqs even if i already have them installed and working". like this option is of any use... erm.

so in app::cpan2pkg, in order not to build the prereqs, i ended up using --ignore flags (flags as in plural form, since using a negative look-ahead regex such as /(?<!$name)$/ do not work). it took me quite some time to come up with this solution, since --ban was not working at that time.

so life was good, i've used cpan2pkg quite some time to create rpms for mandriva, and updated it till v1.0.0. however, since some time, i can see strange things in the packages submitted on upstream buildsystem: the build prereqs were not set. and i had to update the spec file manually, adding all those missing prereqs. i got tired of that, and investigated what happened.

after some experiments, it appears that cpan2dist seems to have somehow changed the way it handles its --ignore flags. ignored modules now are removed from the prereqs completely, and thus the cpanplus::dist backend do not even see them any more. and thus, buildrequires end up empty. of course, --nobuildprereqs still retained its old silly behaviour...

fortunately, it seems that --ban now works correctly (at least on 2 tests that i made). so i've just updated cpan2pkg, and version 1.1.0 should be available soon on cpan, this time really adding the needed buildrequires.

till the next cpan2dist change, of course... :-|

note: i don't want to sound too harsh to jos in this post... i totally understand that cpanplus is still 0.x software - moreover, this is a bug fix in my mind, since --ban was not working.