Normally I don't go to Linux.Conf.Au.
I find it's mix of talks a lot more for the OS-level people, and for systems and solutions types. For programmers working on top of the OS, sometimes the interesting talks can be a little thing on the ground.
Add travel costs to another city, plus a week off work, plus ticket costs, and I always end up with a borderline decision, do I go or not.
This time fortunately, not only is Linux.Con f.Au in my city (Sydney), it's at my former university, which is a 10 minute bus ride away. And to top that off, the talk gods have seen fit to accept me as a speaker, so it's not only free, but I get a chance to hob nob with the far-more-illustrious-then-me speakers.
And the speaker's adventure to the aquarium was awesome. Note to other speakers, they won't let you go into the water over the 0.05 alchohol limit. God only knows why though, maybe they are concerned about you spewing on the fishies. But still an awesome trip.
Apart from the ThreatNet (tentatively renamed to ETN, the Evil Tracking Network) development, which has seen a LOT of interest and several people suggesting I do a lightning talk on it, my biggest focus has been the hallway track.
The opportunity to have representatives from every major open source language, and ALSO every major linux distribution, is the perfect opportunity to make some progress on solving what is, in my opinion, the last big unsolved toolchain problem.
And that problem is package dependencies.
Now, that sounds fairly boring. And really, it is. But it's also fiendishly difficult to solve, which pisses me off. And I like to solve the problems (like spam and not having a Perl parser) that piss me off.
The problem is really twofold, in that no languages have a good way to represent in the original canonical source, what dependencies the code has. Or at least, while they often have intra-language deps ok, they almost never seem to represent inter-language dependencies properly.
The big failure in CPAN installation is that we can't cascade installations over into other languages. That is extraordinarily hard to do.
Further, we only represent source dependencies. Most people install code via distribution binary packages.
And it's simply not feasible to package 11,000 packages by hand for EVERY downstream operating system. And that's just CPAN. Add Ruby Gems and eggs, python's cheese factory, CTAN, CRAN, JSAN, and you end up with tens of thousands of packages, most likely something in the 50,000 package range.
The nearish arrival of Perl 6 and Parrot also means we can't delay fixing this problem much longer.
Parrot will mean that cross-language dependencies will not just be more possible, it means they will become COMMON.
My current solution concept is some form of common dependency grammar. This means you need some sort of universal multi-language package identifier, and then you need a dependency specification that is sufficiently rich, resulting in some sort of standard file that the packaging systems for EACH of the languages could export to.
From there, each of the distributions and operating systems could then use that file/grammar to map the dependencies into their own packaging systems.
So I've been doing what I can this week to bounce the idea off as many distro and language folk as I can. There seems to be some tentative acceptance for the idea, but little concensus over exactly what it might look like. My guess is that a single package will end up as some form of URI, potentially with a dependency on it including something encoded in the query part...
http://cpan.org/class/Foo/Bar?version=0.25
... or something like that.
At the very least, I'm hopeful that I'll reach some concensus with the Debian folks for doing more-thorough Debian module auto-generation (they currently have only 1,100 of the 11,000 modules packaged). That said, having now attended a Debian packaging tutorial, Debian packages seem to have a LOT of weird files and stuff that need to be made, so it's hard to know how easy it will be.
But the Debian folks are certainly looking interested in better CPAN integration, which is a relief.
One of the nicer ideas that was discussed at the speakers dinner, was that it might be possible for Linux Australia to sponsor a "Packaging Summit". Some sort of specific event where we can sit a bunch of people from the languages and distros down together for a few days for the sole purpose of hammering out an agreement on downstream metadata packaging standards.
This would certainly smooth the process immensely.
On a seperate topic, the most interesting talk of the day for me was the kernel maintainers panel, with kernel maintainers for a bunch of distros speaking. Standing out from the various items discussed was one surprising (for me) attitude, which I'll paraphrase.
We hate Xen. Xen is dead. Long live KVM and Rustyvisor.
While I don't understand why SPECIFICALLY, I did get quite clearly that the kernel folks in general don't like Xen's approach and like the new ways better. And of course the point was made that both of these new things are young.
But it did surprise me somewhat that there was so much animosity to Xen, given that in the virtualisation miniconf talks Xen seemed to be the main topic of conversation.
So I think it might be worth me paying a bit more attention to this soap opera. :)
I guess you know it, but if not:
Mark Overmeer is working on something called cpan6. He also tries to solve the inter-language depency problems you're describing.
