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.
Regards,
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
