1 |
On Sunday 02 October 2005 08:08 pm, Ciaran McCreesh wrote: |
2 |
> On Sun, 02 Oct 2005 19:58:19 -0400 Dave Nebinger <dnebinger@××××.com> |
3 |
> |
4 |
> wrote: |
5 |
> | a) are there limits to the size and/or complexity of the ebuilds that |
6 |
> | are accepted into portage? |
7 |
> |
8 |
> Well... |
9 |
> |
10 |
> * Too much complexity is often a sign that you're doing something |
11 |
> wrong. |
12 |
|
13 |
Well that's always the possiblity ;-) |
14 |
|
15 |
> * Too much complexity often suggests that upstream's build system is |
16 |
> annoyingly broken. |
17 |
|
18 |
This is it. Zimbra, if you're not aware of it yet, is another one of those |
19 |
LAMP-like distributions with a twist. Instead of Apache, it's based upon |
20 |
Tomcat, and their distribution includes a ton of other stuff (i.e. postfix, |
21 |
mysql, jdk, etc.) that gentoo's already got. |
22 |
|
23 |
So how I'm approaching it is a little twisted, but the basic steps are: |
24 |
|
25 |
1. unpack zimbra's distribution. |
26 |
2. apply patches to get their initial build to live within the sandbox rather |
27 |
than /opt/zimbra (like they expect). |
28 |
3. apply patches to their iniitialization scripts to have the configuration |
29 |
scripts they would normally build in /opt/zimbra in the sandbox, then run |
30 |
said scripts. |
31 |
4. Combine info from those configs, known values at build time, and values |
32 |
from existing (installed) configs, swing back through the code base applying |
33 |
patches and sed scripts to make the code conform to the local system. |
34 |
5. build the distribution war files in the sandbox. |
35 |
6. for installation, re-distribute the files from their scatter-brained |
36 |
distribution to use a more FHS and/or Gentoo friendly approach. |
37 |
|
38 |
Step 4 is necessary because they store a lot of default values (inappropriate |
39 |
values for an existing package installation) within their ldap (populated |
40 |
from an ldif) as well as hard-coding in the source files (for values they |
41 |
choose not to go to ldap to retrieve). This is further complicated because |
42 |
there are shell scripts, java source files, and configuration files to make |
43 |
passes through to fix things up. |
44 |
|
45 |
So yeah, things are pretty complicated due to the upstream build system |
46 |
expectations. |
47 |
|
48 |
The good news is that the ebuild is full of embedded comments ;-) |
49 |
|
50 |
All in all, though, this has been a great ebuilding educational experience. |
51 |
Such a large distrib to boil down into it's component parts, coordinating |
52 |
unpacking vs compiling vs installing, etc. I'm pretty much exposing myself |
53 |
to all the knooks and crannies of portage ;-) |
54 |
|
55 |
> | b) If there are and I end up going beyond them, is there a |
56 |
> | recommended methodology for relocating some of the functionality? I |
57 |
> | mean, can I put code into scripts in the files directory and freely |
58 |
> | execute from there? |
59 |
> |
60 |
> eclass. |
61 |
|
62 |
Cool, eclass it is, but a few more questions arise out of this direction: |
63 |
|
64 |
1. Can I use /usr/local/portage/eclass for development/testing? |
65 |
2. Do I create a single eclass, i.e. zimbra.eclass, to represent an eclass for |
66 |
a specific package or do I generate multiple eclasses based upon |
67 |
functionality? For example, I've got a gres function, a /var/db/pkg query |
68 |
system, etc. |
69 |
3. Do eclasses get submitted on the same bug report as the ebuild submission, |
70 |
or do they get a bug report of their own? |
71 |
-- |
72 |
gentoo-dev@g.o mailing list |