Re: [gentoo-dev] Ebuild limits?

[Dave Nebinger]

On Sunday 02 October 2005 08:08 pm, Ciaran McCreesh wrote:
> On Sun, 02 Oct 2005 19:58:19 -0400 Dave Nebinger <dnebinger@××××.com>
>
> wrote:
> | a) are there limits to the size and/or complexity of the ebuilds that
> | are accepted into portage?
>
> Well...
>
> * Too much complexity is often a sign that you're doing something
> wrong.

Well that's always the possiblity ;-)

> * Too much complexity often suggests that upstream's build system is
> annoyingly broken.

This is it.  Zimbra, if you're not aware of it yet, is another one of those 
LAMP-like distributions with a twist.  Instead of Apache, it's based upon 
Tomcat, and their distribution includes a ton of other stuff (i.e. postfix, 
mysql, jdk, etc.) that gentoo's already got.

So how I'm approaching it is a little twisted, but the basic steps are:

1. unpack zimbra's distribution.
2. apply patches to get their initial build to live within the sandbox rather 
than /opt/zimbra (like they expect).
3. apply patches to their iniitialization scripts to have the configuration 
scripts they would normally build in /opt/zimbra in the sandbox, then run 
said scripts.
4. Combine info from those configs, known values at build time, and values 
from existing (installed) configs, swing back through the code base applying 
patches and sed scripts to make the code conform to the local system.
5. build the distribution war files in the sandbox.
6. for installation, re-distribute the files from their scatter-brained 
distribution to use a more FHS and/or Gentoo friendly approach.

Step 4 is necessary because they store a lot of default values (inappropriate 
values for an existing package installation) within their ldap (populated 
from an ldif) as well as hard-coding in the source files (for values they 
choose not to go to ldap to retrieve).  This is further complicated because 
there are shell scripts, java source files, and configuration files to make 
passes through to fix things up.

So yeah, things are pretty complicated due to the upstream build system 
expectations.

The good news is that the ebuild is full of embedded comments ;-)

All in all, though, this has been a great ebuilding educational experience.  
Such a large distrib to boil down into it's component parts, coordinating 
unpacking vs compiling vs installing, etc.  I'm pretty much exposing myself 
to all the knooks and crannies of portage ;-)

> | b) If there are and I end up going beyond them, is there a
> | recommended methodology for relocating some of the functionality?  I
> | mean, can I put code into scripts in the files directory and freely
> | execute from there?
>
> eclass.

Cool, eclass it is, but a few more questions arise out of this direction:

1. Can I use /usr/local/portage/eclass for development/testing?
2. Do I create a single eclass, i.e. zimbra.eclass, to represent an eclass for 
a specific package or do I generate multiple eclasses based upon 
functionality?  For example, I've got a gres function, a /var/db/pkg query 
system, etc.
3. Do eclasses get submitted on the same bug report as the ebuild submission, 
or do they get a bug report of their own?
-- 
gentoo-dev@g.o mailing list