On Sunday 02 October 2005 08:08 pm, Ciaran McCreesh wrote: > On Sun, 02 Oct 2005 19:58:19 -0400 Dave Nebinger <[EMAIL PROTECTED]> > > 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@gentoo.org mailing list
