Re: New package managment (fbsd ports)

[Steve Baker <sjbaker1@airmail.net>]

Erik wrote:

> > That's never going to be acceptable - when a new package is announced,
> > people
> > want to download it immediately.  Nobody is going to want to wait while
> > someone updates a centralized /usr/ports directory - and then go to that
> > site and download the new /usr/ports, install *that* and only then get
> > that game!
> 
> this would differ from debs and rpms how? :) And how about dependancies? if the
> pingus autoweb isn't updated iwth the newest version of clanlib referenced,
> then it will get an old version of clanlib...

Well, that wouldn't be such a terrible thing I think.  We know that
pingus
will run with that version (because the pingus maintainer says so) - so
that's OK.  Also, I propose that the game maintainer can use some degree
of "wildcard" to say stuff like "Any version of ClanLib 1.2.34 or later
but
not 1.3.0 or later (because the API will probably change then)"

> RPM's have been critisized because they have no real central repository,

A central repository is A Bad Thing.  You wouldn't want the entire
World-wide-web
stored on a single central server would you?

I'm aiming for a *WEB*-like thing with links.  A central server for ALL
Linux
packages is already unlikely to be possible - just imagine what it'll be
like
when there are 10x or 100x the number of Linux users and maybe 50x the
number
of packages.

> > Also, whichever site maintains that directory is going to feel the
> > 'slashdot
> > effect' with frightnening regularity.
> >
> 
> definitly :) that's why I was thinking cvs and distributed repositories stored
> at sun and ibm and metalab/sunsite. They got the cpu/mem/bandwidth to cope.

Weeeellll - they seem pretty heavily loaded to me.  Also, they may
*just*
be able to cope right now - but not when Linux is 100x bigger and 100x
more
people are using it.

> > There is a political issue too.  Suppose I wrote a piece of software
> > that
> > the maintainer of /usr/ports didn't approve of?  Suppose they refused to
> > add my package to it for some reason?
>
> Suppose the debian maintainers decided not to use your package? suppose the
> redhat ppl decided not to? the suse ppl? We put this kind of trust in people
> with alterior motives already. If some non-profit commitee was formed, they
> could provide some form of quality control.

But with a distributed system, I can put out my package on my web site
and
maintain it all myself.  I don't care if the distro's don't carry my
package.
 
> > However, the more I think about it, the more I think the scheme I
> > outlined yesterday is superior.
> 
> you only think that cuz it's yours :)

Well duh!  :-)

> hell no, if there's a commitee, then they submit the port updates or new ports
> to the commitee, who in turn adds it. There are what, 2 ppl running freshmeat?
> They seem to cope with quite a bit of work fairly well. I think there're 3
> people doing slashdot? they even verify that the stories are worth giving a
> rats ass about (sometimes)

Have you ever tried to get slashdot to run a story?  They accept less
than
1% of the stuff people send them.  Freshmeat don't do much for each
entry,
they basically parrot whatever description the author sends them - right
or
wrong.

> If the autoweb way gets implemented instead of the ports way. And a program
> calls for libblah, and automatically downloads and installs version x of
> libblah. Then another program needs libblah of version y, what happens? does it
> know that a different version was installed? does it upgrade, or attempt dual
> residance? Does it install the new one partially over the old one, breaking the
> first program? How do you enforce sane dependancy checking?

All of this would be under the control of the library author since all
the mechanisms for dealing with this will be in his libblah.ag script.

One program downloads libblah.ag and executes it with:

   libblah.ag --min_version=1.0.0

...which installs (say) version 1.1.2 (the latest wizz-bang version
that day) because libblah isn't detected (by that same script) on this
machine.

When the second program is installed, it also downloads libblah.ag
(which may have changed since the last time) - and runs it with:

   libblah.ag --any_version

...then the script detects version 1.1.2 is installed and therefore
does nothing.

If instead that second program had run:

   libblah.ag --min_version=2.0.0

...then it would be up to the libblah.ag script to decide to upgrade
or attempt to load multiple versions.  Since that script is written
by the library's maintainer, he can decide whether an upgrade from
1.1.2 to 2.5.6 is reasonably safe - or whether dual versions is the
way to go.

Alternatively, the second programs' autoget script could have run:

   libblah.ag --exact_version=1.1.0

...in which case version 1.1.2 (which is already installed) is not
acceptable so either multiple versions can be handled (in which case
1.1.0 is downloaded and installed) - or they can't (in which case,
the script should simply flag an error and exit).

At any rate, we place all these problems in the hands of the library
author - where they belong.

Having multiple versions of a library installed *should* be possible if
the author is following the linux-base rules (I admit that PLIB
doesn't).

Looking in /usr/lib, I can see the following libMesaGL files:

libMesaGL.so      -- a symlink to libMesaGL.so.3
libMesaGL.so.2    -- a symlink to libMesaGL.so.2.6
libMesaGL.so.2.6  -- an actual library
libMesaGL.so.3    -- a symlink to libMesaGL.so.3.1
libMesaGL.so.3.0  -- an actual library
libMesaGL.so.3.1  -- an actual library

Isn't this how things are supposed to work?

If the author doesn't follow the rules then there is a problem
anyway - autoweb won't make that either better or worse.

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