Menu Close

Self v.3

This has been a long time putting to keyboard; a thought that has brewed in the back of my mind for over a year now, but something only worthy of a “musings” label. One of the reasons its taken this long to commit even a comment on is that I have a basic problem of going from idea to commitment (ask my wife, she’ll vouch for that with a case history that is staggering).

It all started with the basic thought: I miss the person I used to be. Oh, I know, many get there, especially when you reach the end of your twenties. You remember the kind of person you were when you were a kid, even a teenager, then you realize how much real life bogged you down into a limited context that leaves you with very little time between work and sleep, and what little there is admittedly wasted on things like TV and your Playstation 2 (recent example for me would be Jak 3, not only a little too quick to beat but it ate the better part of all my free time for three days).

So I started thinking, why can’t I be that person again? And that’s where Self v.3 came from. If you consider through adolescence as v.1, your 20’s as v.2, then v.3 is the next logical step. What would I like to see in v.3? A rebirth of v.1 with the lessons learned in v.2. I’d like to see myself be literate again; I’d like to be able to end the day and look back and see something accomplished.

I’ve started to get that feeling lately with Gentoo, but I want more (don’t we all?). I have so many half baked ideas and projects lying around that I know with a little love and attention could actually work. But instead I sit on my duff and do nothing.

I want to quit my bad habits, become a better person, etc., etc.. I want a personal renascence, where there’s no need for a v.4 because it turns out v.3 was the pinacle of the person I could become. The key to this is, of course, actually following through, not putting this off with “well, when I write this tool it will make it easier for me to take care of this,” or setting a start time/date that isn’t the here and now.

At one point I actually sat down and wrote a list of the things I’d like to be able to accomplish in a day, then added in the time blocks for things I am unavoidably commited to already like work and commute (but not sleep), and ended up with a 26 hour day without any sign of rest in it. Nice approach, but I think I have to find a way to be more reasonable on what I want to accomplish.

Shoot, even writing this entry (and if you’ve noticed a discontinuity, here’s why) has taken me the better of a week and I don’t even think it addresses completely what I originally started out to say. I’ll try and revisit this again later, when my mind is clear, clock is empty, and brain cells are willing.

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… 😉

%d bloggers like this: