[Devel] Zimbra FreeBSD Build and Packages

Tony Publiski tonster at tonster.com
Mon May 30 17:06:02 CEST 2016


I can comment on a couple of things, but overall I think Quanah would have more complete answers. :)

----- Original Message -----
> From: "Malte Stretz" <mss at msquadrat.de>
> To: devel at lists.zetalliance.org, "rs+zetalliance org" <rs+zetalliance.org at trust64.com>
> Sent: Monday, May 30, 2016 4:30:21 AM
> Subject: Re: [Devel] Zimbra FreeBSD Build and Packages
> 
> Hi,
> 
> Quanah or Tony will probably add some more details but here are some
> starting
> points:
> 
> On Sunday, 29 May 2016 20:32:28 CEST Ray wrote:
> >[…]
> > I think the right way to do it is clean up the build system and
> > help
> > make it be more portable. Then getting it to build correctly for
> > the
> > active branches and get a FreeBSD Port / pkgs going. Once this
> > works
> > ports to other Operating Systems should be much easier.
> 
> That cleanup of the build system is already in the works. It is not
> yet full
> up-to-date but you should start here to get an overview:
> https://wiki.zimbra.com/wiki/Building_Zimbra_using_Git#ZCS_8.7_and_later
> 
> There's one thing you've got to keep in mind:  There are essentially
> two build
> systems:  One to build the required binary thirdparty packages, and
> one to
> build Zimbra itself.
> 
> The former was totally revamped for 8.7, the latter will switch to
> Maven at
> some point. It is all a bit in a flux still.
> 
> > Now to my questions:
> > * I got the ZCS git repository, but I can not find either the 8.7
> > or the
> > 9.0 branch, what are their branch names?
> 
> 8.7: judasprriest-870-foss
> 8.8: judaspriest-foss
> 9.0: main-foss
>  
> > * What would be ideal to concentrate on, 8.6, 8.7 or 9.0?
> 
> Definitely 8.7 right now if you want to get something usable soonish.
> Maybe 8.8
> if you're looking more long-term.
> 
> > How long until 9.0 would be stable?
> 
> Don't hold your breath :-)

9.0 is probably a couple of years out, and when it is released may not at all resemble what's currently in the main-foss repo.  I'd disregard it entirely for now, as it could quite possibly be a wasted effort to get that working.

> 
> > Are there big differences in the build-system between those 3
> > versions?
> 
> Yes, a lot, especially between 8.6 and 8.7 and laer.
> 
> > I have seen that with 9.0 will change to maven, will this change a
> > lot in
> > the build system?
> 
> I think so.

I think "definitely maybe" is the best response I can offer atm. :)

> 
> > Or are the changes relatively easy from 8.6 through 9.0?
> 
> I think the changes will be coming step-by-step so if you get the
> current
> state of things to build, you'll have to replace only pieces later
> on.
> 
> > Will those changes effect the shell scripts and make files?
> 
> Depends on which you mean :-)

Moreso in 8.8 (or whatever comes after 8.7, though currently the planned designation is 8.8) than in 8.7.  What's in 8.7 now is close to what will be in the final 8.7.  In 8.8, when we really tackle repacking in phase 2, there will be many more changes. Ultimately, the goal is to pretty much rewrite the installer entirely.

> 
> > * Is it possible to use OpenJDK7 (or 6, 8)?
> 
> Zimbra already depends on and ships OpenJDK 8 as the JRE in 8.6
> (8.5?) and
> later. For building the Java parts AFAICR you still need JDK 7 where
> OpenJDK 7
> should be fine. It should be possible to build with OpenJDK 8 as well
> if you
> manage to feed the proper switches to javac.

OpenJDK 7 should work, though I'd suggest relying on the version of OpenJDK that's shipped with the product as that's what is tested against.  Obviously, the distro would need to ship their own version of that JDK. 

> 
> > * Is it OK to make all shellscripts portable and getting rid of all
> > the
> > linux assumptions (use /bin/sh instead of /bin/bash, correct/detect
> > locations for perl etc.)
> 
> It is not my decision but I am not a big fan of POSIX shell at all
> since you
> loose a lot of functionality for no real gain. Bash is a sensible
> dependency,
> especially build dependency, in my eyes.
> 
> > * Is it OK/Possible to make ZIMBRA_HOME defi nable? (In FreeBSD a
> > location like /usr/local/zimbra is what is expected from a port to
> > install into) . Would it be sufficient to change all the build
> > shell-scripts and makefiles, or are there more elaborate changes
> > involed?
> 
> Theoretically this should be possible already since there is a
> localconfig
> value for that. I'd be surprised if there wasn't /opt/zimbra
> hardcoded
> anywhere though and things will break in funny ways.

This is not supported in the product, and I would strongly suggest not doing that.  There are numerous places in the code where /opt/zimbra is (improperly) hard-coded. You're almost certain to run into problems by modifying ZIMBRA_HOME.

> 
> > * Why does MACOSX build less packages then Linux in the thirdparty
> > makefile? Are those libraries/applications used directly from the
> > OSX
> > system installation? Is it because those form part of the base
> > system?
> 
> Probably since nobody was building Zimbra on Mac OS X for ages anymor
> and that
> part saw heavy bitrot. I'd just go and rip it out completely.

Yeah, OSX was abandoned a long time ago.  It has certainly not been kept up as things have changed, so the effort to support it again would likely be non-trivial.

> 
> > What is the policy on apps/libraries being used from the OS or
> > built them?
> 
> Zimbra ships its own versions of many packages which are normally
> shipped by
> the OS. A prominent example which shows both the advantages and
> disadvantages
> is openssl:
> 
> On the pro side: If Zimbra relied on the OS openssl, it would have to
> follow
> the OS' feature release schedule. Which would eg. mean that mixing
> reverse
> proxies which run on Ubuntu 12.04 and Ubuntu 14.04 would giv eyou a
> lot of
> headaches when it comes to a modern SSL config.
> 
> On the con side: Zimbra has to ship security patches for all their
> shipped
> libraries etc. And of course code duplication.
> 
> I for one come from the enterprise background and like that Zimbra
> gives me
> something I can rely on to behave the same on all supported OSes.
>

We don't support using the OS-supplied packages on many items due to them being often un-reliable.  We've seen numerous issues with some of them (most recently, nc supplied by redhat had major issues with ipv6 support that broke zmconfigd).
 
> > * When doing some cleanups in the thirdpart install scripts I saw
> > that
> > the makefile defines MAKE=make. On GNU make, this variable is
> > already
> > set on startup to the name of the specific make application which
> > was
> > used. On FreeBSD GNU make is called gmake. Using gmake instead of
> > make
> > in the shellscript is rather easy, and if one does not do
> > MAKE=make, all
> > calls to $(MAKE) in the Makefile automatically use gmake when on
> > FreeBSD. Is there some reason this variable gets re-defined to
> > make?
> 
> I don't think this is still the case in the current thirdparty
> packaging code
> at https://github.com/Zimbra/packages
> 
> > * The directory /ZimbraBuild/rpmconf/Build etc. contains build
> > definitions for RedHat, Debian, Ubuntu, etc. but RPM refers to the
> > redhat package manager, I guess this is something which just did
> > not got
> > changed, or do you create the .deb packages from the .rpm's? Is it
> > correct to make changes needed for (Free)BSD in those directories?
> > I
> > started to modify the /ZimbraBuild/rpmconf/Build/get_plat_tag.sh to
> > recognize FreeBSD and return the correct version. Should I just
> > keep
> > modifiying those scripts?
> 
> You should have a look at
> https://github.com/Zimbra/zimbra-package-stub and
> https://github.com/Zimbra/packages.
> 
> > * How would you propose to work and / or incorporate the changes we
> > do
> > on the repository, how can all the interested people help out at
> > the
> > same time? is git.zimbra.com just a git-repository or is it a
> > github
> > project? Do you have distributed work-flows defined?
> 
> Cheers,
> Malte
> 
> 
> 




More information about the Devel mailing list