[plt-scheme] availability of RPM for RH 8.0 and DrScheme 203

From: Eli Barzilay (eli at barzilay.org)
Date: Tue Mar 4 16:07:42 EST 2003

Whew...

So there are two seperate issues -- specific packaging, and package
management...  My previous suggestions on the subject were limited to
the actual packaging, nothing more.  I believe that it is good to have
a binary RPM, since Linux is more popular, it gets the usual crowd
that is just too lazy to read installation instructions when they have
some standard packaging tool, very much like not feeling too great
about Windows packages that don't come with some convenient "setup"
program.  What I did is a manually cooked binary package that does
everything a package installation does except for asking a few
questions and not registering files with the actual packaging system
used.  I believe that this could be done in a much better way with the
plt/install program, but since my thesis is actually going pretty fast
now I don't have time for such hacking...

What I think would be a good goal, is to make install a good script
that can be used by whatever binary package is being used to deliver
the files, so the only requirement from the native packaging is to
unpack the files at the right place (including related administrative
work), and then run the install script which should do the rest.  This
is easy if all files are in a single tree, but one possible problem is
outside files like soft-links to "binaries", manual pages etc.  For
this I think that install should be able to accept some flags that
will indicate the amount of such external work -- for example, it is
probably not a good idea to install a /usr/bin/games link for
/usr/lib/plt/bin/games...  (and I don't think that interactive
questioning is something to rely on in the general package case).

Something along these lines should make it easy to generate different
binary packages, as well as manual installation.

About the contents, I think that aiming for easy packaging by
different systems will make it pretty hard to rely on features like
marking some parts of the package as documentation files, so I think
it shouldn't be a factor -- if anyone will have any problems with an
extra ~20mb then they're very likely to know they're way with
different installation methods anyway.  One more thing is that I still
didn't find any reason not to distribute .zo files, it does take a
long time to generate, long enough for people to think that something
is broken.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                  http://www.barzilay.org/                 Maze is Life!


Posted on the users mailing list.