Hi
For various reasons I have started to package some other software for Gentoo and decided to put together an overlay for LedgerSMB. I wanted to share my experiences here and also looking at where the efforts I have seen on Debian, etc where we can probably make some improvements.
First the good: Packaging the dependencies for LedgerSMB from CPAN was super-easy and straight-forward. It is as simple as using g-cpan to generate an initial ebuild, editing that to ensure that we aren't over-promising, and then writing a metadata.xml. I spent around an hour packaging all of our span dependencies. It was really, really easy.
As a side note, one of the impressions I get from Jame (please correct me if I am wrong) is that one of the headaches here is legal: making sure we have all the right copyright information on all the right documentation, and this right now is a manual process. I will come back to that later.
Packaging LedgerSMB is, on the other hand, very different. On one hand, these are not shared libraries so the build cannot go in vendor perl, and I am trying to support running multiple versions in parallel. Managing the direct dependency tree itself has been as much effort as packaging all of the dependencies. My approach is basically to:
1. Create an ebuild
2. Create a makefile which will overwrite the project makefile
3. Clobber the existing makefile with the new one in the ebuild
4. Point it at a directory (/usr/share/ledgersmb-1.4 for example)
5. Set up Plack (probably Starman at first.
6. Use an OpenRC init script (similar to Sys-V) to start Starman with each of the installed versions
Right now I am on stage 2. Since there is a presumption against bundling, I will use any existing dojo ebuilds and this makes some things harder as well. However already packaging LedgerSMB has proved much more effort than packaging all the dependencies combined.
One of the reasons I would like to see more stuff on CPAN from us is it would probably simplify this a lot. It's easier to have 2-3 optional dependencies each with 4 dependencies than to have 8-12 optional dependencies in 2-3 groups. Also, tracking which options have been enabled poses some complexity. From a Gentoo packaging perspective, the more we can put on CPAN the better. (Yes, g-cpan is not perfect, but it handles 90% of the cases nearly perfectly and once you get an ebuild, updating to a new version is super-easy).
On to where I see some issues with the spinoff modules.
99% of the time I have been contacted by packagers (usually Jame) over packaging questions it is the nuts and bolts of things like copyright dates, changelog entries, etc. I would like to suggest that these can be subject to automatic testing. I would like to suggest the following global rules we can enforce by Travis or a git hook:
1. Copyright dates *MUST* include the current year for *all* modules changed, checked on every commit to master. This is something maybe we could enforce with a git hook.
2. Every tag MUST have a have an associated changelog entry. Again, something we could enforce via a git hook.
There is one specific gentoo situation which is that source urls, being what they are, do not support backpan and cpan transparently together. Therefore I have to keep the overlay current regarding all currently supported versions and change urls to backpan were needed. That's a minor issue though.
On the whole I expect working Gentoo packages in not too much longer and look forward to how we can help make packaging less work.
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.