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
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.
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor