From: fmarshall AT acm DOT org (Fred Marshall) Subject: Installation - A Recommended Structure - Comments? 8 Dec 1998 20:24:45 -0800 Message-ID: <026c01be22c5$1c35eb70$cac8c8c8.cygnus.gnu-win32@mindspring> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit To: "Cygnus32" First, let me say that I'm clearly not "in context" with how things work at the Cygwin "system" level - or how they're supposed to work. Perhaps there's value in that. So, I hope I won't get flamed too badly for making an observation and a suggestion. The observation is valid - because it's what I see. The suggestion may be terrible!! There's obviously a lot of good work being done in making the gnu tools available on WIN32 platforms. Part of the entire effort is intended to make solid tools available to a wide audience. My impression is that only until a person has slugged through the installation processes at least once or thrice (then they may have become part of the intelligentsia) all the information that's being passed around becomes a lot more useful. I wonder if the following makes sense to folks: Background: 1) Cygwin32 is set up and intended to allow porting gnu tools into WIN32 environments. This appears to make sense for two main types of users: - UNIX users who find that not using a WIN32 environment is impossible for various reasons - WIN32 users who want to make use of the gnu tools but who may not be UNIX experts at all and, of course, in addition - the experts out there at 6 sigma of the population who just want to make it happen 2) Arguably, the population of WIN32 users who want to make use of the gnu tools is the largest group of the two main groups and the subset of them who aren't UNIX experts is a large part of the group. 3) Reliably installing these tools is elusive at best. It can get to be really complicated. Witness the many messages where people are failing to succeed. 4) Installation instructions are terse at best and are (randomly?) distributed over a bunch of readme files, FAQs, etc. Some of the important items are labeled or identified in some ways with earlier release numbers - adding to the confusion. So, if this is at least somewhere close, might this be a reasonable recommendation: 5) Each release (of whatever) should be accompanied by its own installation instructions and groundrules (disk space is cheap). 6) Beta testing would urge testing the installation instructions 7) The instructions would be based on a "standard" configuration - perhaps a number of them depending on operating system - but preferably one that is WIN32 OS independent. What this should be might be a very good topic for debate. Granted, there are many possible variations - using various gnu and gnu-related entities that individuals might want to try. However, reaching some agreed level of standardization would help reduce the confusion and focus testing and documentation efforts. Here's a modest recommendation: A) Establish a recommended/standardized WIN32 directory structure that will work well with the gnu tools. - Use it. - Test with it. - Document it and write instructions around it. Write for folks who aren't UNIX experts. Use WIN32 tools and methods where it makes sense. (For example, using the NT "Program Files" directory is probably a bad idea isn't it? bash or sh commands don't recognize this type of name structure). B) Establish methods for setting up WIN32 settings that are important to the workings of the intended gnu environment. - Things like what needs to be in the PATH. - How to get them into the PATH. Even if there are methods created that will do this automatically, this information should be available. For one thing it can be used to check the results and it can be used to manually set up PATH variables. Arguments for and against some of this: Against: Setting directory structures is counter to freedom of expression and suggests a rigid situation with no flexibility. For: Standardizing should not remove flexibility. However, it should prevent errors like: the instructions or some buried code refer to a directory or path that exists on the author's unique system but don't exist on the target. C) Prerequisite installs are problematic. If there are prerequisite installs then there should be some very clear method and map for revealing this. Preferably, there would be a roadmap and instructions for installing onto a "clean" WIN32 platform. Pointing to other entities that are higher up (come first) in an installation hierarchy or sequence can be a major source of confusion and failure - because they change. It seems that a well-structured scheme for doing this would be evident. It looks like there should be a recommendation here - but what? Maybe this is all taken care of by A and B? In Conclusion: If your reaction to this is "gee, what's the problem?" "all of this is already taken care of!" RTFM! Then, I'd suggest that some tiny ingredients are missing somewhere. If not missing, then randomly distributed? Maybe what we need is a better, more visible, list of recommended reading? If your reaction to this is "I agree" then responding to this message with that comment might be useful to see how many such responses ensue. If your reaction to this is to have better recommendations than those above, then that's great! Perhaps at best, this message could be a catalyst. Most respectfully, FCM - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".