Re: ANNOUNCE FDIinstall preview -> further ideas

Eric Auer wrote:

> Hi, first of all, thank you for working on FDInstall.
>
> I have noticed that most of our ZIP do not follow any useful rules for
> directory structure, I suggest the following restructuring, which can
> be either applied to the ZIP files or become part of the installer.
>
> - leading paths called like the program get replaced by the freedos-
>   install directory, for example c:\fdos.
> - all executables end up in $INSTALLDIR\bin.
> - all files in a "help" directory end up in $INSTALLDIR\help\$ZIPNAME,
>   further subdirectories of "help" in the ZIP being flattened out.
> - all files in a "nls" directory end up in $INSTALLDIR\nls - no furher
>   work needed.
> - all other files end up in either $INSTALLDIR\help\$ZIPNAME or in
>   $INSTALLDIR\src\$ZIPNAME based on user decisions or some heuristics.
>
> This is very kludgy, so probably it would be better to push some
> "FreeDOS directory naming standard" again, I would say. A ZIP file
> in "recommended" layout would have contents like this:



Do you  mean, like in the FreeDOS Distribution HOWTO?
<http://fd-doc.sourceforge.net/howto/en/distrib.txt>

Don't re-invent a "standard" when it has already been documented elsewhere:



[..] The FreeDOS Install program  does  not  have  any  firm
standards on what its directories should be named.  However,
I strongly recommend adhering to these few rules when creat-
ing packages for installations:

1.   Do  not  name the C:/FREEDOS path.  Your package should
      only include subdirectories of  the  C:/FREEDOS  direc-
      tory.   You will want to do this because one user might
      prefer the path C:/DOS and another might like C:/DOS.

2.   Programs and system driver files related to the FreeDOS
      project should go under a subdirectory called BIN.  For
      example, the BIN directory will contain the XCOPY, FOR-
      MAT,  FDISK,  and  other utilities typically associated
      with DOS.  You may or may not choose  to  install  your
      editors here.

3.   Help files for installed programs should go in the HELP
      subdirectory.  The extensions on those help files  will
      depend  on what help viewer you are using.  A help sys-
      tem based on GNU Info might use .INF, while  one  based
      on HTML files might use .HTM.

4.   Source  code  should  go  under  a  subdirectory called
      SOURCE.  Each package should have its own  subdirectory
      under  the  SOURCE directory.  For example, source code
      to this install program would go under  SOURCE/INSTALL.
      Source   to   the   XCOPY   program   should  go  under
      SOURCE/XCOPY, and so on.

5.   Documentation that is not part of a  help  system  (for
      example,  release  notes)  should  go  under a separate
      directory called DOC.  Each package should have its own
      subdirectory under the DOC directory.



In other words, a package called FOO would have this zip file layout:

  BIN\
  BIN\FOO.EXE
  DOC\
  DOC\FOO\
  DOC\FOO\README
  DOC\FOO\COPYING
  HELP\
  HELP\FOO
  NLS\
  NLS\FOO.EN
  NLS\FOO.ES
  NLS\FOO.DE

And the source package would have this zip file layout:

  SOURCE\
  SOURCE\FOO\
  SOURCE\FOO\FOO.C
  SOURCE\FOO\MAKEFILE.BC
  SOURCE\FOO\FOO.H
  SOURCE\FOO\DOC\
  SOURCE\FOO\DOC\FOO\
  SOURCE\FOO\DOC\FOO\README
  SOURCE\FOO\DOC\FOO\COPYING
  SOURCE\FOO\HELP\
  SOURCE\FOO\HELP\FOO
  SOURCE\FOO\NLS\
  SOURCE\FOO\NLS\FOO.EN
  SOURCE\FOO\NLS\FOO.ES
  SOURCE\FOO\NLS\FOO.DE

>
>
> File "foo.zip":
> \bin\foo.com
> \doc\foo\readme.txt
> \doc\foo\changes.txt
> ...
> \help\foo
> \nls\foo.en
> \nls\foo.es
> ...
> \src\foo\foo.h
> \src\foo\foo.c
> \src\foo\makefile
> \src\foo\compile.txt
> ...
> ^- the leading \ are of course optional. The idea is to install the whole
> hierarchy under $INSTALLDIR, which can be for example c:\fdos\ ...
>
> I wonder if it would be possible and make sense to have this kind of 
> directory
> structure at least for most of the standard packages.
>
> A quick and dirty implementation for the -installer- would be to first
> unzip to a temporary directory, then copy any executables anywhere in 
> there
> to $INSTALLDIR\bin, and then let the user decide for every other file 
> whether
> it should end up in help, doc\$ZIPNAME, nls, or src\$ZIPNAME. The 
> installer
> would then log where it has copied the stuff in the same format as 
> zipinfo -1
> would have done, thus it would have virtually reorganized the ZIP file 
> while
> installing it. To save time, it would be cool if you could answer the 
> help /
> nls / doc / src question once for whole directories (possibly 
> including sub-
> directories). For this, the user should be given a "unzip -Z -1 | 
> list" (or
> more, not list) before all the question-asking starts.
>
> I think that all this is probably lots of unnecessary work to implement,
> but I am not sure if it is feasible to have most of our ZIP files 
> organized
> in a way that they contain some sane directory structure already.
>
> Feel free to share your opinions about this everybody. At least I
> am prepared to structure my ZIP file contents a bit more nicely to
> ease the installation with FDINSTALL.
>
> Now some feedback on the current FDINSTALL implementation:
> When in doubt, use IF to ensure the existence of the PREFIX and LOGDIR
> directories and the PACKAGE itself...
> Hm. A prefix allways causes simulate? Or do I misread here?
> You do not use %UNZIP% so you need not un-set it :-).
> Now about uninstal.bat:
> Hm. Shouldnt you popd before you RM ...@...? And if rm gives an
> errorlevel, you should probably avoid deleting the logfiles if rm
> signals failure.
>
> Thanks for your efforts so far, I am curious to see the next version.
>
> Eric




-- 
-----------------------------------------------------------------
This email message has been encrypted using the ROT-26 cipher.