Re: New package managment

["Bryan Patrick Coleman" <linuxgames@excite.com>]

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.

> 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. 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. 

> 
> 1) A *few* people will have none of those libraries installed.
> 2) Most people will need one or two of them
> 3) A few people will already have all of them installed.
> 
> There is no way that bundling everything into one huge install
> is going to address those users.
> 

You can do three things. I is really up to the developer to make things easy
on the end user. :) Offer just the binary and just the source. A package
which contains a little of every thing. And a full blown dist just for the
purpose of playing the game :)

> For people in group (1) it's unlikely that we'd have bundled GLIDE or
> Mesa into the tarball.  For people in group (2), we *might* guess right


I would definalty NOT include major libs like Mesa or GLIDE, As for guessing
right did you have to pull it down off the net or did it come with your
Linux distribution?

> and pick the set of libraries that they need.  For people in group (3),
> it's all a huge waste of bandwidth.
> 
> Not only that, but there is no doubt that we'd include versions of some
> libraries that were hopelessly out of date - nothing out there in Linux
> land stands still.

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. Without haveing to
become a developer. We dont want to tell them its the linux way or windows!

> 
> A much better scenario is the one I proposed with the (poorly named)
> autoweb scheme.  People in group (3) pull down the game - it checks,
> finds all the stuff it needs and then installs itself.  People in
> group (2) pull down the game - it pulls in the odd library they are
> missing (or which is out of date) and installs them - then the game
> itself.  People in group (1) have a long wait on their hands - but
> c'est la vie.

same Idea I think.


> 
> > When you install the package it sees tha need to install the libs as
well
> > and does so.
> 
> A Good Thing - but why pull down all those binaries if we don't have to?
>  
> > I also am going to include source in the packages so that binaries can
be
> > built from the same package. Even using the option to build staticly
linked
> > binaries. Basicaly the libs would be installed for the build and then
> > removed after the binary is built.
> 
> ...causing people to have to download the damned things again whenever
> they
> grab another game that uses them.

If its an older lib the chances of that are small. Game developers tend to
be on the bleading edge I have noticed. How many more games are going to be
written with the old clanlib?

> 
> In the late 1990's, disk space is extremely cheap - but for many people
> outside the US, bandwidth is incredibly expensive. For many people
> inside
> the US who don't have cablemodems or whatever, bandwidth is incredibly
> S-L-O-W.

I have a 14.4 modem:)

> 
> > I would like to say something in the defense of static linking. There
is
> > currently a glut in the lib market with new projects cropping up all
the
> > time. If each new game comes out and is using a different lib you really
are
> > not gaining anything. Plus what if you really want to games that use
> > different versions of a lib that are incompatable. Say clanlib. Then
you
> > could have the new clanlib installed, but have the Pingus game do a
static
> > link with the old lib.
> 
> 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.

> 
> I agree with Pierre - we don't need yet another binary package manager.
> RPM's and their ilk have that covered.
> 

I would not divorce it from rpm's just an enhancment. So you could still
just pull down the rpm :)

> We don't need a new source manager either, autoconf/automake are really
> great.

Again developers tend to stay on the bleading edge. autoconf/automake things
barf at least half the time. What end user is going to chasing around new
versions of the build tools. I think all developers should try building
there packages on at least the newest stable release of say redhat or
caldera. Debian to be safe since its still on the old kernel. We should not
be forcing average joe to keep there systems more upto date than the
distro's. Unless you just want developers playing your game.

> 
> Anything you did in that area would simply create Yet Another Standard -
> which would be A Bad Thing.  Doing what you propose would make matters
> worse - not better - because the poor luser gets yet another set of
> commands to master.

New standards are not always a bad thing agp vs isa video cards is a good
example. But that is not what I am trying to do. I just want to build on
whats there. And hopfully there will be no new commands and less of the old
as I want to creat a mindless toy for instalation. Not really mindless but
with a mindless "mode"

> 
> Look - we are *just* getting to the point where RPM and
> autoconf/automake
> are reasonably "standard" - most binaries come in RPM form and most
> sources
> as autoconf/automake.

why not srpms?


> 
> What's needed is the higher level thing that ferrets out all the
> components
> of a big package and assembles it from that various RPM's and tarballs.

Thats what I plan on :)


- Bryan Coleman




________________________________________________________________
Get FREE voicemail, fax and email at http://voicemail.excite.com
Talk online at http://voicechat.excite.com