Well, I'm surprised you got as far as you did without any help. The entire install process is still a WIP, and that's why this is still considered a "friends and family" release. I really wish you had spoken to us before trying it, as I guarantee I could have saved you a lot of time.
To begin with, I apologize for the pathetic state of the documentation on the website. All the real docs are NOT in the wiki, they are in pod files that are part of the source code, in a few git repos. What you see on the website was the dribble we had to throw together to make the bureaucrats happy so we could get the initial OSS release done. We have a LOT of docs that I've written, and Jerry Gay is working on getting them published automatically when we commit them via git. I hope that Jerry can get something published in the next couple of weeks. I'll let him comment on the status of that sub-project. Now, there are several overlapping issues here. First of all, we have to deal with installing and configuring EFS itself independently from installing and configuring *content* into /efs/dist. The first problem is tricky because EFS is not a simple system you install on one box. It's infrastructure. You need a database, an NFS server, and at least one host on which to run efsd. This is all very highly automated, once you have put the infrastructure in place, and written a single config file for the bootstrap process. Then, a single script (util/efs_bootstrap_all) automates the entire process. It takes about 5 to 10 minutes. That's the part you were missing documentation for. Installing products into the EFS namespace is a bit of a black art, but for open source products, I have an application called efsdeploy that automates this, and I've used it to build a lot of stuff so far. However, until you get past the bootstrapping problem, you can't use efsdeploy. It does a great job with GNU configured based products, and CPAN modules, and can be extended to automate other build systems as well. The dependency on perl5.10 is a moot point. Installing EFS itself does NOT require changing the OS perl, and in fact, we assume /usr/bin/perl remains unchanged. Part of installing EFS requires building perl5.10 for use by EFS, but during the bootstrap process it gets built into /usr/efs, so that we're entirely separate from the OS installation. If you're building on one of the platforms we've already integrated, then efs_bootstrap_install will simply download a pre-compiled tarball of perl5.10, and ALL of the CPAN modules it requires, and install it into /usr/efs for you. The hard part of the bootstrap process is still far from complete, and a huge WIP. If you look at the EFS 2 environment (assuming you still have access to your previous and my current employer's infrastructure), you'll see that EFS runs out of /efs/dist, and NOT out of /usr/efs. That's possible because it sits on top of a HUGE list of dependencies that have been integrated with /efs/dist already. One of the things I'm working on is automating the process of rebuilding all of that infrastructure, without which, EFS is very hard to use. Thus far, I've automated the most critical part: the compilers. I'm working now on automating the integration of perl modules, so that EFS-based perl is easier to use. All of the things everyone takes for granted in the legacy EFS 2 environment took a few years to build, and a lot of it was trial and error. Now, we're working to make THAT an automated process, but it's a long road. One of the things that will make this a little easier is that we have a prototype mechanism for sharing pre-compiled releases, but that, too needs more work. Right now, we're still MONTHS away from what I could consider a GA release. I'm very sorry that your initial experience was so negative, but this is still an alpha release, and won't be considered beta until we've worked through more of these issues. FWIW, I've been telling anyone who would listen that we still have a long way to go before we can replicate the EFS 2 environment. Sadly, very few have listened. What we need are users willing to help us solve these problems, but thus far everyone wants to wait until this has matured. Given the very limited man power we have, and the lack of help we're getting from the early adopters, I'm not sure we'll reach that "GA" label this year. On Tue, Jun 15, 2010 at 10:47 AM, Anthony Skipper < [email protected]> wrote: > I'm curious about what can be done to simplify packaging and installation > of EFS. I've encountered a number of problems that make it a bit difficult > to use OpenEFS in both corporate and commercial environments. > > The first is the basic install instructions. Threre don't seem to be any. > I've now worked through installing OpenEFS a couple times on ubunutu and > partially on Centos 5.3 and would be happy to send you my notes if that > would help as a starter? I have to say that hacking through MakeInstall.pl > and debugging dependencies is never fun. Even less so if you happen to be a > Perl neophyte like myself. Unfortunately I haven't had time to make expect > scripts for all the basic scripts I put together, but maybe it would be > helpful regardless. It seems like the optimal scenario would be to get to a > point where someone could just "yum/apt-get/rpm OpenEFS", and then just jump > to configuring the client and server conf files. It would be especially > nice to have both the CPAN modules and other dependencies in a single > package. > > The other issue I encountered is the dependency on Perl5.10. Many of the > folks we work with are on some combination of RHEL/Centos 4.8-5.1. But all > those versions and even the later 5.3 & 5.4 series use a version of Perl > older than 5.10. If you know RHEL and Centos then you know that replacing > the version of perl that comes bundled with the platform can break so many > things. (The only way I know to make it work is to strip the OS down to the > ground and rebuild all the packages all the way back up, which isn't a valid > approach in the real word) It would be a lot easier if both the install > script and the code itself could be configured to use a separate perl > installation than the default of the platform. > > -- > Regards, > Anthony > > _______________________________________________ > EFS-dev mailing list > [email protected] > http://mailman.openefs.org/mailman/listinfo/efs-dev > >
_______________________________________________ EFS-dev mailing list [email protected] http://mailman.openefs.org/mailman/listinfo/efs-dev
