Re: [MiNT] Re[2]: GEM boost

[Evan Langlois <Evan@CoolRunningConcepts.com>]

On Sun, 2005-07-17 at 12:49 -0400, Mark Duckworth wrote:
> I don't feel that Linux's lib problem is anywhere near as bad as MiNT's.

MiNT doesn't have a problem - its all static!  So things are guaranteed
to work as expected, and it runs and loads faster.

> First of all, we would be able to steal gentoo's revdep-rebuild tools
> pretty easily, and secondly the lib api generally only changes on major
> revisions of libs.  In 2 years of running gentoo, I've really only had

The gentoo portage system was supposed to take care of all the issues.
revdep-rebuild is there because the first fails.   The idea of
incompatible libraries and having to keep old libs around for different
programs seems like a problem that doesn't have any "clean" solutions in
the Linux world ... at least not from my point of view.

> to run revdep-rebuild once.  Under MiNT, as package maintainers, we can

Once?  Do you know how cool "links" is with -g to do graphics on the
console?  The fastest graphics on the console that don't require you to
mess with fbset or any mouse drivers is "directfb".  Set the directfb
USE flag and links will be compiled to use.  Its really slick.

Too bad that every upgrade to directfb is incompatible with older ones.
Directfb is optionally included in many different libraries, such as sdl
and mplayer and its plugins.  Now - imagine recompiling everything that
uses directfb, sdl, mplayer, and everything that uses libsdl or any of
those libs.  Sound like fun?

I finally changed emerge -u world to emerge -uD world && revdep-rebuild
&& prelink ... whatever prelink flags.  And this is a system built from
source and designed to not have dependancy issues.

On a binary system, you'd simply never be able to replace directfb or
anything that includes it - keep em around forever.  

My point was that as soon as you start getting into dynamic libs, you
need a system of keeping track of what libs are installed, which apps
use them, if its safe to update them, and when you install an app, you
have to be sure the dependant libs are there, so you need an installer
instead of just copying the .app or .prg.   So, you have something like
the RPM database or the Windows registry to record it all and get
corrupted.  Do ATARI users really want all that?  Is it all worth it?
Is there a better way?

> simply try to figure out everything that is broken by the upgrade and
> recompile it and release a -2 rpm... the users won't know.

I certainly hope the Atari doesn't become an RPM based system.  RPM
isn't exactly the most user friendly thing in the world to deal with.