Re: New package managment

[Steve Baker <sjbaker1@airmail.net>]

Bryan Patrick Coleman wrote:
> 
> On Sat, 25 Sep 1999 02:46:04 -0500, Steve Baker wrote:
> 
> I should have read all my mail first and then replied. I like the points
> brought up in this email better
> 
> <snip>
> > No - that's silly.  Now someone who already has Clanlib and Hermes will
> > have to download all that code all over again.
> >
> 
> Individual packages would still be available.

It doesn't help - Joe Q Public is a complete idiot.

Either:  He'll upload the whole damned thing anyway - and complain
         about the size of the download - or just bitch about how
         huge and bloated Linux packages are....
Or:      He'll download the smallest thing and you'll *STILL* get
         snowed under with stoopid complaints about it being hard
         to install.

Having a script he can run that can figure out what he needs, download
the minimum set for him - and automagically install it all for him is
what he needs.

There is no doubt it's technologically possible - and not much doubt
that it's both desirable and needed.

All it really takes is for someone to implement a tool to generate the
script - and a bunch of games and utility writers to make use of it
and promote it until it becomes a standard.

> > In my case, I'm writing a new game. It's pretty tiny - just 3,000 lines
> > of
> > C++ code.  But the end user needs:
> >
> >   PlumbCrazy (the game)
> >     which needs PLIB
> >       which needs GLUT
> >         which needs Mesa
> >           which might need GLIDE
> >       and libpng
> >         which needs Zlib
> >       and libjpg
> >
> > That turns the teeny tiny game (just a few K of download) into a package
> > of about 10Mb.
> 
> In this case I would just bundle PlumbCrazy and PLIB the other would belong
> to other groupings.

But people who already have Tux_AQFH or FlightGear or Majik3D or other
PLIB
games would end up downloading it again and again for each game (and
it's
a half meg download - so that's a BIG deal for people paying $0.25 per
minute for Internet access)...and for people who don't have those
things,
there is still the likelyhood that they'll have to do the chase from
site
to site to get the libpng, libz and other parts.

> Like I mentioned in the other email The main purpose
> would not be for download but for cd distribution. But large down loads are
> nice too. I like the fact that Mandrake and Storm Linux both have iso images
> available for down load.

OK - well for CD distribution, the problems are a little different.

I agree that you should have all the libraries (including Mesa, libpng,
etc)
on the CD - and now you need a tool to only install those parts that are
out of date....but the existing tools seem to manage that kind of thing
quite well.

> Here is an interesting side point I would like to make. Developers dont mind
> pulling down this and that from all over just to build a game that may or
> may not work or even build. (that not an attack on any one persons game) The
> average normal everyday joe would like to play games too.

Right - but if this process of pulling down the component parts were
automated, the end user would even realise that we were visiting a half
dozen
web sites to get the stuff he needs.  The total time/bandwidth would be
identical to a binary package containing *exactly* the parts he needs.

In the case of someone who already has some of the components he needs,
the download/install time will be very much better.

> > Dynamic linking has that nailed. That's why you'll see ".so" files with
> > version numbers after them.
> 
> I have seen that not work often enough to be extreamly skeptical that it
> could in all cases.

!!!  Why not?  !!!

> Again developers tend to stay on the bleading edge. autoconf/automake things
> barf at least half the time.

They do?

Only when something they need is missing (in my experience).

What other causes are there for failure?

> What end user is going to chasing around new
> versions of the build tools.

Nobody - which is why the build tools should be shell scripts - because
that's something we know everyone can run.

That's why the './configure' thing works so well (IMHO).

> I think all developers should try building
> there packages on at least the newest stable release of say redhat or
> caldera.

That's what I do...I have a vanilla SuSE install.

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