[ut2004] No love with linux installer

[Sean Hamilton]

| The installer needs to unpack a bunch of stuff
| that is compressed, prompt for an install a cdkey,
| install the correct binaries based on CPU
| architecture, prompt for new discs, give some idea
| of how much progress it's making, recover from i/o
| errors; it's not a simple shell-script sort of
| thing.

I disagree.

- The user can do the unpacking. Un-tarring and running
  a script (like every other unix package out there) is
  unlikely to be the demise of Linux gaming. If the
  script is on the CD, no unpacking should be necessary.
  (See my comments below.)

- The shell provides facilities for prompting, and no
  doubt they are far more useful than UT's installer's
  curses-interface. For example, they make no effort to
  prevent pasting.

- Detecting and acting upon the correct architecture is
  trivial, or better yet, why not just ask?

- Prompting for discs is also trivial.

- The current installer gives a progress bar which gives
  the progress of the current file, but doesn't indicate
  how many files there are.

- In my experience, the installer does not recover from
  I/O errors. I installed onto a partition without enough
  room, once it was full, it claimed all the copies were
  succeeding, despite the screen being garbled with short
  write messages. Eventually it claimed the game was
  successfully installed.

Another annoyance: if I accidentally press a key when it is copying, then when it goes to prompt for the next CD, it interprets that keypress as an "abort" request, doesn't confirm this, and just bails out. Any sane program would catch SIGINT and clean up nicely. Pretty hard to accidentally hit ^C. At the very least, empty out stdin before prompting.

| Because linux gaming will never accept commercial
| acceptance if our solution to everything is "here's a
| shell script you can debug yourself."

More likely, Linux gaming will not receive commercial acceptance if even a user with a few years' experience takes an hour just to get the thing installed, complete with kernel recompile. I'll give you it was a bit of an anomaly that I didn't have Joliet extensions support in my kernel, but the installer gave me absolutely no clue that the problem was that it couldn't find the file on the CD.

My suggestion is that the linux-install.sh script on the first CD ask its questions, then generates a makefile in ~/ut2004install. The user is then told to switch to that directory and make install. The makefile can have for each file a dependency on the destination file, as well as md5-summing, prompting for new CDs, etc. Then, even if the power goes out half way through, we can just make install again and resume where we left off. Any errors are printed to the user instead of being silently discarded. If there's a problem, make bails out, the user fixes it, and make resumes where it left off. All these standard tools don't exist just to take up space, they're actually useful. I know this isn't too well thought out, but already it's better than what we have now. I'm happy to write the code if there's interest.

-- 
Sean Hamilton <sh at bel.bc.ca>