Beware the ides…

Beware the ides my friends. I’ve noticed (before I finally caught up with this digital age thing and started deleting mail that was old or that I didn’t care about anymore) that of late, on or around the 14th of the month, a flamewar ensues. Maybe this month it will be about planet…or on planet as I read through some of these blog exchanges, but you are forewarned: the ides are a bad time for the Gentoo commune’s peace. Maybe I should change my nick to Brutus for a few days…

Module-Build in the eclass – I’ve been sitting on a change to the eclass for long enough. Expect to see, well, hopefully nothing at all, as the change to the eclass should be smooth as silk 🙂 I don’t want to dep the module itself – that’s overhead for folks that don’t install anything that uses Build.PL’s, so I racked my brain over it and decided that in order to drop the style=builder from the ebuilds (which I know is silly but made perfect sense at the time) is to instead check for the presence of a Build script, and if its there and you don’t have module-build installed, to die off and ask the user to report the ebuild being emerged as a problem child. Thanks to the arch’s for testing and marking stable module-build (many moons gone past now since they did that for me, making me the bad seed in this). I’ve tested it out a few hundred different ways and it appears to work great – basically it’s a QA check that if the ebuild doesn’t dep module-build, and you don’t have it installed, there’s a problem to report. This should close out the 3 or 4 bugs open on the subject to boot.

Bug 84744 – the mini-blog – I’ve gotten a bit too verbose in this bug as I use it as a whiteboard for my thought process, but I think I’ve gotten everything straight now. My steps will be to take the list of modules/versions that come with each install of perl and:

  • Make sure we are up to date
  • Block older versions of modules from installing with perl’s that come with newer versions

I had thought about trying to go through the tree and making this a (foo||perl-version) type dep, but then it struck me on my long drive this morning that that would get in the way of future updates or security fixes. If I had gone with that (never mind the technical dificulties of making the call on packages that just dep the module, not a particular version) we would have had a situation eventually where we needed to bump foo because of a security/functionality fix, but all those users who had met the perl-version half of the dep would never see it – which defeats the purpose. Yes, I acknowledge that there will be folks who get modules via ebuilds that they already have from the perl-core, but at least they will still have the flexibility of getting newer/improved/patched/fixed versions later on. And for those reading this and wondering why bother to even include core modules as ebuilds, its all about backwards compatibility folks. If package Bar depends on foo-3, and the user has perl 5.8.5 which only comes with foo-2, this gives them a means of using Bar without having to upgrade their perl. Sure, over time we drop support for the older perl’s as things progress, but this gives our more stable/static folks the ability to use new packages without having to upgrade perl itself.

Perl bump coming (again) – I know there’s been a lot of this going on lately, blame security conscious folks for taking a look at perl if you must. Due to bug 79685 we will be bumping perl again this morning. I still have doubts that this will fix the rmtree vulnerability completely, but can’t prove it. Just strikes me that if the script is running against an nfs mount, and that mount is having sync issues, you could be verifying that the stat of the dir is the same and begin deleting/acting before the sync is done and the stat changes.

modperl/libapreq brains welcome – rac tackles these best he can and I’m admittedly ignorant while I work on the rest of the dev-perl tree. There’s a good number of bugs open on this, mostly related to getting the reverse @INC working in mod_perl, which I think rac has done, but again, my ignorance displays itself 🙂

g-cpan – yes, it needs updating. yes, there are bugs open on the subject. no, I haven’t had the time to look at them. Yes, I intend to one day. 🙂

wow – who knew I could say so much in one morning on only a few cups of coffee. Hope this isn’t a trend or something.

Paving for 5.8.6

Guess first off is heyas Planet Gentoo! OK, real post…84744 is in the tree for tracking the dev-perl ebuild conflicts. I’d like to see at least everything bumped so that it is at least current with what comes with 5.8.6, better yet would be to add || perl-5.8.6* to all inclusion ebuilds, but one beast at a time. Now if someone could just explain why iggy gets to have bugs filed about him… 😉

what memory problem?

I’m an idiot – that’s right, you read it here first. That resident memory size I was complaining about is unavoidable in a sense – after all, the size of the perl binary is a factor in any running perl process. Duh. So if I’m really worried about total memory usage, then I need to consider recombining the two processes (reporter and validator) back into a single entity, which I had avoided so that if one died the other would keep running.