Source package missing items

[exothermic]

I downloaded the source package, and there appears to be quite alot of holes in it (for those who can't interpolate between the cvs build docs, and what needs to happen)

1.) Thirdparty root doesn't even contain a Makefile for building
2.) perdition isn't in Thirdparty root either, which means no Makefile for that dir either (is this no longer need for M2?
3.) Where would someone find snmp-5.1.2.tar.gz? I can find different builds of net-snmp, but not with those version numbers
4.) There is no make file in ./sleepycat/ so that fails in the make
5.) Being that this is a source build it would be very nice to know which packages can be built from the latest stable source tree, and which ones need to be the specific ones asked for in the build_cvs (like clamav for instance)
6.) Most source build docs discusss the various packages, and the needed config options, and options that will break the overall build. This was more what I was expecting.

Thanks

Miles

[marcmac]

1. I believe that there's a Makefile in CVS.

2. Perdition isn't integrated yet - that's on the list of things we're doing in the near future.

3. Grab a different version, and edit the version info in the makefiles.

4. Again, CVS should fix this.

5. We've tested the listed versions. No known problems with newer versions, but no promises, either.

6. We haven't had the time to test across all versions - that's one of the reasons that we ship the binary package as a complete set, because we can do so with confidence.

[exothermic]

Originally Posted by marcmac

1. I believe that there's a Makefile in CVS.

2. Perdition isn't integrated yet - that's on the list of things we're doing in the near future.

3. Grab a different version, and edit the version info in the makefiles.

4. Again, CVS should fix this.

Are there any intentions of putting together a source package where the instructions aren't "Grab missing items from CVS?"

Originally Posted by marcmac

6. We haven't had the time to test across all versions - that's one of the reasons that we ship the binary package as a complete set, because we can do so with confidence.

I wasn't infering to testing across any other versions, much less all versions. I'm just suggesting a souce install doc that is typically written for linux programs. Pretty much anyone can write this if they are very familer with the makeup of the program. (or any dilegent person with some level of knowlege could work backwards through your Makefiles) Like the folling format:

INSTAL PREREQs:

1.) install prereq 1
2.) compile prereq 2 > vers # --with-some-config=options
3.) place bins for this package here (here is suggested for your sanity, but they could reside anywhere, if so you would need to edit at least these files, maybe more we don't know but don't say we didn't warn you)
4.) get source for this and apply these patches then compile and install

INSTALL zimbra:

1.) compile zimbra item1 --with-some-config=options -with-install-package1=here
2.) make;make install etc
3.) compile zimbra item2 -with-some-other=options --with-install-package3=here;make;make install etc

I'm sure you have all seen this format before even in the packages that you use for prereqs.

Also another nice thing would be to provide a repository for all the packages that you suggest especially the jdk one since it can't be simply wget'd

I'm just coming at this from a typical open source solution, where they first and formost persent the source with a clean laid out way of how to make it work with the various components, then they offer some binaries, but only as an afterthought (or in your case because they need to support a specific consumer base) because they know how very few people a binary actually applies to. In this case it seems like you are all interested in pushing out the bins, and then providing this snapshot of source code that you worked on so you can say "Hey guys we are open source"

Don't take that the wrong way, I love your end result, and I think you have an amazing product here, and I'm extreemly grateful for making it publicly avalbile like this, but I don't think the owness lies on you to demonstrate that the source works on every distro out there. If you provide an abstracted source install doc complete with a complete needed source tree, then I think you would be surprised at the different distros and even OS ports that it starts popping up on.

my two cents

Miles

[marcmac]

The missing items from the source install are in CVS - we also include a source tarball with each release (which I think is what you have). So, while the next release tarball should have the missing items, if you want them today - you should go to CVS.

As for the "install prereqs with version >= x, install zimbra" source installation doc - zimbra isn't currently set up for abstracted locations of postfix, ldap, etc - our system is tightly integrated with them, and expects to find them in specific places. This is why the cvs install doc says "get version X, put it here, and run our makefile".

The decision not to provide the source for the 3rdparty packages was deliberate - partly to save ourselves space/bandwidth. It's true, you can't wget the jdk - Sun doesn't want you to - so you have to download it via a browser.

We are an open source software company - with an emphasis on an integrated solution that is easy to install and configure. We don't want our users to be forced to do the dependency chase for all of our 3rdparty pieces, we want you to be able to install the system and get it running quickly and easily. To be honest, we know that's not the typical open source way, but we don't see it as a liability, we see it as a strength.

[exothermic]

Originally Posted by marcmac

We are an open source software company - with an emphasis on an integrated solution that is easy to install and configure. We don't want our users to be forced to do the dependency chase for all of our 3rdparty pieces, we want you to be able to install the system and get it running quickly and easily. To be honest, we know that's not the typical open source way, but we don't see it as a liability, we see it as a strength.

I see your point, but you could really add more to your strength, by simply providing an simple per package install guide, and source package that was capable, this doesn't mean using different builds, or different paths either. These two concepts aren't mutually exclusive.

By the way I think there are some files missing out of Postfix in the current source down (non-cvs), but I'm not really sure.

Miles