Re: New package managment

[Steve Baker <sjbaker1@airmail.net>]

Ingo Ruhnke wrote:
> 
> Borko Jandras <bjandras@public.srce.hr> writes:
> 
> > Ever considered putting PLIB in the source of your game?
> 
> That was AFAIK the case with Flightgear some version ago.

Yes 0 it was - but that was before I had the PLIB web site properly
set up.  For the period FGFS had it's own copy of PLIB, it was a
serious pain in the ass.  It's much better now that they pick up
the generic PLIB.

> > That is, when you say "make dist" that sources for PLIB appear in
> > the source tarball of your game.
> 
> The thing is that the games would get much larger. Plib is ~1MB...

(Only because of all the example programs and their data - it would
only be about 250Kb without all that stuff)

> that is just to much do, to just download it because the user may not
> allready has it. If you also want to try this with Glut, Mesa and
> friends than the thing would get much to big.

Yep.  Also there is the issue of old versions being uploaded because
the author of some game didn't grab a new set of libraries for many
months.

> autoweb would be the solution, we need just somebody to implement
> it...

...and a better name. Erm, how about "autoload" with the file extension
being ".al"?
 
> BTW. How would autoweb check for the installed libs?

I was thinking that is could just look for the existance of the
actual library file itself.

  eg: mygame.al would contain...

   #! /bin/csh

   # Check for PLIB...

   if ( -e /usr/local/plib/lib/libssg.so.1.0 ) then
     wget http://www.woodsoup.org/projs/plib/plib.al
     ./plib.al
   endif

   # Check for libpng...

   if ( -e /usr/lib/libpng.so.2.1.0 )
     wget http://www.cdrom.com/pub/png/png.al
     ./png.al
   endif

   # OK, all the libraries are loaded

   wget http://www.mygame.org/mygame.tgz
   gunzip mygame.tgz
   tar xvf mygame.tar
   rm mygame.tar
   ./configure
   make
   make install

Obviously it needs to be more sophisticated than that - it's got to
check the version number of the library that's installed and the
acceptable range of library versions for this package - also
there would need to be LOTS of error checking and the ability to
go and look at mirror sites for the packages it grabs.

> A special
> configure script could do the job, but how to parse the configure
> output? Could config.cache be used for that or do we need another
> file, which is generated by the configure script. And how to stay
> compatible with standard configure of the game, so we won't have to
> maintain two similar files (acinclude.m4 comes to mind)?

I was assuming that you would need to provide a configuration file
for the actual autoload program that would generate the mygame.al
script.  I don't thing there is the right kind of information present
in any of the existing autoconf/automake stuff.

We'd need:

  For each library:
    The name of each library or other package. 
    The minimum acceptable version number for that package.
    (Optionally) the maximum acceptable version number.
  * A unique file name (minus version number) for that package.
  * A list of places where it might be installed.
    The web site to fetch the autoload file for the library from.
  * (Optionally) a list of mirror sites.

This brings up the issue of how much of the work should be done in
mygame.al and how much in the libraries' .al file.  Possibly the
information marked '*' above should be in the library.al and not
in that of the calling package.

In fact, you could simply delegate the test for library presence
to the library.al script.  That would mean redundantly downloading
lots of library.al scripts for libraries that are already installed,
but those scripts should be tiny - and the advantage would be to
punt the issue of how to detect the presence of that library in
the correct version range onto the author of the library - which
is probably A GOOD THING.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjbaker1@airmail.net (home)  http://www.woodsoup.org/~sbaker
sjbaker@hti.com      (work)