Date: Thu, 29 Jul 93 14:51:11 MDT
From: bob AT plk DOT af DOT mil (Bob Conley)
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Version Packaging


There have been a number of recent problems relating to the way the
various revision levels of DJGPP are packaged.  Usually the conversation
goes something like the following:

>> I recently switched to V1.10 of the GO32 and friends.
>> Now, my programs, using graphics don't work anymore;
>
>get pub/msdos/djgpp/pub/csdpmit1.zip's go32.exe

or

>Since the "-c" option is working, and "gcc hello.c" isn't, it sounds  
>like you may be missing ld (the linker) which is in a separate  
>binutils package.


At best there seems to be an underlying confusion for some of us on
which components need to be connected to have a 1.09 or 1.10 system.
Speaking just for myself, I certainly am confused enough about 1.10
that I am reluctant to try it out, expecting that too much time would
be spent trying to navigate the maze than would be balanced by the
return on the investment.

May I suggest that there may be a better way to collect together the
various files associated with a given release level?  Just a suggestion
(others may have much better ideas along these lines) would be to have
separate directory nodes for each revision;  for example, DJGPP_1.09
could hold _ALL_ of the files associated with this version (similarly,
directory DJGPP_1.10 could hold _ALL_ of the files associated with that
revision).  For someone intimately familiar with all the internal
interrelations of this rather large body of software, it may seem obvious
that compiler "A" needs to be used with linker "B", or the program needs
to be loaded with graphics library "C".  But for the uninitiated (or for
the person who merely wants to _USE_ this software without becoming
a GPP-hacker---and I consider myself in this catagory), there seems to be
a level of complexity and confusion which could be avoided.

My opinion is that it should be possible to enter a single directory
path at the FTP site and find there all the relevant files one needs to
obtain in order to have a functioning DJGPP system at a given revision
level;  it should not be necessary to discover that the go32 from another
directory node is required, or that the linker from a different utils is
needed.  That way, if there are real incompatibilities between the
successive releases of DJGPP, one can easily migrate up or down the
seqence to find the one which works with a given application.  In addition,
it provides a better migration path for us in that we can quickly install
the new release---1.10 for example---determine whether it is compatible
with our application suite, and revert to 1.09 if problems are found.

Of course, there may be files which are common to more than one revision,
and for maintainability it is desirable to have only one copy extant.
The FTP site can handle this in a number of ways.  Perhaps the simplest is
to have the physical location for a given file be the directory associated
with the revision where the file is introduced into the system.  If a
subsequent revision uses the subject file, a symbolic link could point
from the directory of the new revision to the actual file.  The user of
DJGPP could decide on how to handle this sitiuation on one's own system,
and optimize for simplicity, minimum file space used, etc., without any
impact to the outside community.

     Bob Conley
     conley AT plk DOT af DOT mil