Re: [AD] Unix-specific distributions

[George Foot <george.foot@xxxxxxxxxx>]

On Sun, Dec 05, 1999 at 02:50:26PM +0000, Shawn Hargreaves wrote:
> George Foot <george.foot@xxxxxxxxxx> writes:
> > RPM gets a little confused because the only file it installed gets deleted 
> > too, so uninstalling the packages just results in an error message about 
> > the file.
> 
> Urgh, that does sound awkward. Would it perhaps be possible to do this with 
> a preinstall script instead?

A preUNinstall script could do it. :)  I'll sort that out.

>                              Use the preinst to unpack the .tar.gz and build 
> the libs, then let RPM be in charge of copying the libs, and just use 
> postinst to delete the source tree. That way RPM would know exactly which 
> files it had installed. I don't know anything about how this actually works, 
> though, so I'm just guessing here :-)

Unfortunately it doesn't work like that for binary RPMs.  For
source RPMs you can do something like that, because the spec
file has portions which are effectively shell scripts and there
is provision for these scripts generating new files and removing
old ones.  But nobody in the real world knows how to use SRPMs,
so I think we should stick with RPMs.

An RPM has an archive containing the files to install, and knows
where they go, and it has four scripts -- preinstall,
postinstall, preuninstall and postuninstall.  When you install
it, unless you tell it to skip the scripts, it runs the
preinstall script, then unpacks the files into their target
locations, and then runs the postinstall script.  When you
uninstall, it runs the preuninstall script, then deletes the
files it installed, then runs the postuninstall script.

We don't have a preinstall script.  Our archive contains just
our tarball, which goes in /usr/local/lib IIRC, and our
postinstall script unpacks this, deletes the original,
configures, builds, installs, and if it's the enduser version it
deletes the build tree afterwards.

To undo this, we need a postuninstall script which deletes the
installed binaries and (if not enduser) the build tree as well,
and creates a dummy tarball to suppress the warning about not
being able to find it when we uninstall.  But that won't work,
because RPM checks that the file hasn't been modified before
uninstalling it I think -- or maybe that's only true for config
files?  Hmm.  I'll check up on this.  We could just not delete
the tarball in the first place, of course. :)


On Sun, Dec 05, 1999 at 02:40:10PM +0000, Shawn Hargreaves wrote:
> I think tools like dat are enough outside the normal course of operations 
> that we don't need to include them. I'm not so sure about the setup program, 
> though: is that part of Allegro that we need to supply, or an optional 
> component that the programmer should include for themselves if they want it?

I think that provided it builds cleanly there's no reason why
developers shouldn't ship it with their program.  Especially if
it can be included directly into their program -- I thought this
was already possible, but you say it wasn't until recently.

>                                                       I'm not sure how 
> important that option really is, but if we distribute the setup ourselves, 
> we are certainly discouraging people from being more creative in how they 
> use it.

I like this option a lot.  For one thing, it ensures the config
file is placed in the directory where the game sees it.  Using
the build system I just posted about, this will require root to
do the configuring, but I don't think that's a problem at all.
If anything, it's a problem related to distribution.

> Although, to date I've noticed almost nobody actually including the setup 
> util along with their games. I'm not sure whether that means that we need to 
> provide it separately, or that popular opinion has decided that it just 
> isn't needed, though.

To date, nobody has been distributing games for Unix systems
for use by people who aren't themselves Allegro developers.  In
Linux at least, it's essential that the setup program is used,
just for trivial things like getting mouse input.

This makes me think how much nicer (and easier) Allegro is to
get working than SVGAlib was when I was trying to get Quake to
work.  I never got SVGAlib to work outside VGA resolutions, and
couldn't persuade it to use my GPM repeater data.  We must have
done something right in Allegro somewhere. :)

> > You can either leave it as a separate script, or call it from the end of 
> > `zipup.sh' -- or merge it with zipup if you want to.
> 
> I think it has to stay separate. I run zipup.sh in win95,

Ooh, naughty. :)  I'd forgotten just how Unixy DOS/Windows can
be when you install the right tools.

>                                             But the tarball has to be 
> created in Unix, so it can get the executable flags set right.

Executability isn't a huge problem, since, even if `fixunix.sh'
is only readable, you can type ". fixunix.sh".  But the idea of
the tarball is that nobody has to run `fixunix.sh' anyway, so I
suppose all the scripts called by the makefile would then fail.
Still, as far as fixing a DOS-generated distribution is
concerned, you only need to dtou the script, you don't need to
chmod it as well.

George