On Fri, Jan 30, 2009 at 1:57 PM, Melchior FRANZ wrote:
> A design goal of flightgear has always been to keep
> itself contained in one area and be a good citizen of your hard drive.

This assumption suggests a badly laid out file hierarchy.

No; it does not.
It's tailored for FlightGear developers who throw source and data in the same location.
But on Unix platform-independent data belong to /usr/{local/}share/
while source is in /usr/{local/}src/ or in someone's HOME or a project
dir. And Linux distributions follow this rule. They put data in
/usr/share/FlightGear/ (or, shudder, in /usr/share/games/...).
The reason for this separation is that platform independent data can
be put on read-only mounted partitions and be shared across several
machines via NFS. Source must be editable.

Yes, but I'm sure you are aware that there are (at least) two schools of thought on this subject, each with unique pluses and minuses.

For simpler installations, what you propose works pretty well.  For more complex installations designed to meet the needs of many users, or users with many needs, you can often discover a requirement to maintain multiple versions of individual software packages on your system(s).

The traditional unix scheme, and most linux packaging schemes, assume only one version of the software at one time.  If you need multiple versions you start versioning the binary, and all the other subtrees that get stored on your hard drive so you can maintain separation and/or defining unique names for the different package versions ... php2, php3, php4, etc.  But what do you do if you need to have two variants of php3 on your system for some reason (again, think multiple users, or users with multiple needs.)

There are certainly many sys-admins that prefer to install each package in it's own root/prefix so it's easy for multiple versions to coexist, easy to remove an entire version, easy to add a new version, easy to relocate an entire version as part of system maintenance.  How about running a "live" version off a CD?

And then don't forget that we are also keeping windows and Mac and possibly other platforms in mind as well.

I think you are being a little quick to rush to a conclusion about the validity of one layout over another.  And sure, your scheme doesn't prevent a self contained directory layout, and in the grand scheme of things this is a relatively minor point.  I was just a little surprised to see you attack this issue with such vitriol, especially when it reverses a long standing design goal.

What's wrong with defining the following on your machine? You'll
probably be the only who does it, but that's fine.   :-}

 export FG_SOURCE=/wherever
 export FG_ROOT=$FG_SOURCE/data

Well, as you pointed out, I don't need anything that points to my source code, except when I'm compiling, and then --prefix works just fine.

But your prefered scheme locks us into a policy that all flightgear related files that we might need to find at run time need to be located below the data directory.  And then to work around that we need to define separate environment variables to point to other things.

You can also have that with FG_ROOT and FG_SOURCE, or whatever layout
you prefer.

Sure, we can make a lot of schemes work.  Sure the current approach is inconsistent if you dig down deep, but I don't see transitioning from one set of inconsistencies to another really helps advance the cause.
Which name calling? It's the ambiguity that bites us, and lots
of people who don't understand it. And why should they? There
shouldn't be an ambiguity in the first place.

Sure I agree, but go back and read your CVS commit comments, read your inserted warning message, read your reply to my (what I thought was a courteous) offline question to you.  But I do understand your tone if you are assuming that question always == attack.
So what do you suggest? That FG_ROOT must always point to a
directory containing a directory named "data/" which contains
the data? Or shall we rename FG_ROOT to FG_DATA, and let
FG_ROOT point to the source, and FG_DATA to the data? In any
case, there should be no assumption that data is in the source
directory. It doesn't belong there.

I personally would like to see FG_ROOT point to a top level directory that could contain an entire FlightGear installation.  Below that we would have sensible defaults ... like data/ bin/ scenery/ but these could be overridden with FG_DATA FG_SCENERY FG_AIRCRAFT, etc.  I think it make sense to have a set of reasonable defaults, but I don't want to *force* an installation policy.

Melchior, I simply asked you a question based on your CVS commit log messages and explained my perspective. You immediately spun this around to the list implying I don't like open discussion.  Well here we are.  Yes the current scheme is ambiguous and inconsistent.  The quick hack to go one direction is not good as you point out.  The quick hack to go the other direction is also not good (I feel.)

What probably needs to happen is a bit more open discussion, and then someone is going to have to dive in and do some hard work to fix it in a way that make logical sense (is consistent) but that doesn't make too many policy and file system layout assumptions.


Curtis Olson: http://baron.flightgear.org/~curt/