re: ANNOUNCE FDInstall preview -> further ideas

Wolf <[email protected]>
Newsgroups gmane.os.freedos.devel
Message-ID <[email protected]>
On Mon, 21 Oct 2002, Eric Auer wrote:

I had some pare time left, so I'll reply to the first part as well :)
>
> Hi, first of all, thank you for working on FDInstall.
>

My pleasure. It's fun to work on FreeDOS again.

> 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.

a good feature, allthough some big things like freemacs could have it's
binaries in %INSTALLDIR%\lib\%PACKAGE% and then some appropriate
batchfiles 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.

Again I propose to use either %INSTALLDIR\lib\%PACKAGE%,
%INSTALLDIR\misc\%PACKAGE% or %INSTALLDIR\shared\%PACKAGE% or even just
%INSTALLDIR\%PACKAGE% for the exraneus files.

>
> This is very kludgy, so probably it would be better to push some
> "FreeDOS directory naming standard" again, I would say.

I agree. Should this be a task for the FreeDOS DOC gang?

> ^- the leading \ are of course optional. The idea is to install the whole
> hierarchy under $INSTALLDIR, which can be for example c:\fdos\ ...

I agree.

>
> 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.
>

I think it would. It would also be a lot easier for the installer...

> 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.

Well if the other maintainers are willing to change, their packages, It
would really help. Perhaps we could say that the programs that can have
this done, are FDInstaller-compatible. The prblem is the limited
functionality of the batch-language, even with batch extenders, and the
random zipfile-structure. some don't have any sub-dirs, others have
packagename\bin ...\src ...\doc etc. so it would be hard to guess. If
the install program takes longer to execute( because it has to ask so many
questions), than it would to unzip to a temp dir, and then copy stuff -
nobody would use FDInstall, which kind of defeats it's purpose.

I view the FDInstall program to be an easy way to install a program, or to
update. Preferably so that it could run without any user-responce.

>
> 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.
>

I am too. It would be nice to have all packages structured this way. Hmm I
just thought of something:
the zipfiles that have their version in the package name might have to be
renamed, or then the FDInstall prog would need another argument...

--Wolf

-- 

  |\ _		Maintainer of DOG - The New Shell!
  |  .\---.	http://dog.sourceforge.net/index.php
 /  ,____/	http://sourceforge.net/projects/dog
/   /C:\DOG\>_	[email protected]

Humpty Dumpty sat on a wall
Humpty Dumpty had a great fall
All the king's horses and all the king's men
Couldn't put Humpty together again.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.