Darren Stalder <[EMAIL PROTECTED]> writes: > 2) Ignore criteria #3 and just be forced to build multiple Perl > versions of packages.
Blech, that would result in me having to double build nine packages (unless we make a serious push for threading, in which case double that again), and although most are fairly quiescent, two or three see regular updates, and at least one (libhtml-parser-perl) is being updated often right now. Mostly, though, I just wonder if it would be worth the effort it's going to require, even if we don't make people maintaining perl libraries do extra work. Specifically, it seems to me (in the absence of worthwhile statistics) that the only people who would want the lower memory usage badly enough to go to the trouble of replacing a standard package with a more obscure one are the same people who are probably going to most begrudge the performance hit: people who have perl running _constantly_ doing important system tasks on lower-end machines. (Or perhaps people using INN, which I will admit could win _big_, given all the places I gather it embeds perl these days, but those are a small minority, I think.) Furthermore, I _thought_ (though feel free to just say "You're wrong" and I'll shut up) that most of the perl interpreter would end up being shared because of Unix COW semantics anyway. So I don't know that this is sounding like it's really worth it. I mean, do we want to put all this work into 5.6 with Topaz just around the corner? I forget what the glyph for evil grin is exactly. Mike.
