One of the most common mistakes a developer can make is never look or work outside their usual environment. By never looking outside their own little sandbox, they risk losing sight of which improvements happen outside of their world, which they could easily factor in. This is why I always look at what Fedora, Debian and Ubuntu do, for instance.
Given my involvement with Ruby packaging, one of the things I should try to avoid covering myself with is Ruby itself; unfortunately trying to look at Python packaging is not something I’d be keen on doing anytime soon, given the state of python.eclass (please guys, rewrite it, sooner rather than later!). But at least tonight I spent some time looking at Perl modules’ ebuilds.
The main reason why I went to look for those is because an user (Grant) asked me to add Google’s AdWords library for Perl to the main tree, but Perl is something I wanted to look at for a while, since I wanted to set up RT for my customers and the new versions require a few more dependencies.
At any rate, looking at Perl ebuilds for me is not too unnatural: while the fact that there is a single Perl implementation makes it much easier on them to implement the phases, the rest of the set up is not too different from what we have in Ruby land.
What seems to be more common there is that they also set HOMEPAGE by default if none is set, since it seems like a lot of modules only have an homepage as part of CPAN, which is only different in the Ruby world due to the fact that most of the projects are managed on GitHub, which makes that their default homepage.
Having finally to take a good look at the g-cpan tool, I have to say that I think that all the trials for a g-gem tool or similar are quite out of target: instead of creating a tool that creates and install ebuilds for the pre-packaged extensions, we should have coordinated with RubyGems upstream to provide a few more details — such as a way to explicit the license the extension is released under, which CPAN does and RubyGems doesn’t, you can also see Mandriva struggling with the same issue in the final questions on my FOSDEM talk — and at that point we could have just created a tool that prepared a skeleton for our own ebuilds, rather than something fully automated like it has been tried before.
Anyway, I really like the idea of trying to package something you’re not usually used to, makes it easy to find what is different and what is similar, in approaches.