Front page | perl.perl5.porters |
Postings from March 2000
Quoting mjtg@cus.cam.ac.uk: :"Simon Cozens" <simon@othersideofthe.earth.li> wrote :> FAILED: :> Storable (sv_yes, sv_no, sv_undef undefined) :> Curses (na) :> Term::ReadLine::Gnu (na, sv_undef) : :Lack of pollution strikes again. We're going to see a lot of these. :Lots and lots and lots and lots, clogging up perlbug and c.l.p.* . I don't understand this for Storable. I thought Storable was behaving nicely with the 5.6 branch. I even recently added the #include <patchlevel.h> explicitely in Storable-0.6.9 to cope with future 5.6, as I've been told by someone. Nowadays I stick with stable Perl versions and only support Storable for the latest Perl version, because I lack the tuits to do otherwise. This means that Storable *might* no longer compile with 5.005 once 5.6 is out, because I'll fix it to work with 5.6, which might break 5.005... I can't force people to upgrade to the latest perl version, yet I cannot maintain Storable endlessly to be backward compatible. The current Storable does not compile with 5.004, and I don't know how to fix that, because the people complaining lack the skills to fix it themselves and send me the patches, and, frankly, I lack the time/motivation to do it. One alternative would be to include Storable in the core, which would mean no incompatibility problems like those: since many modules depend on Storable working, and due to its sensitivity to Perl internals, I've come to the conclusion that it's the only sensible choice in the long term. Despite being close to the 5.6 release, I ask you that you consider it. Raphael