Re: GNUstep repository (was LinuxSTEP + Integration of apps)

[Dennis Leeuw]

Tim Harrison wrote:
<snip>

> > One of the problems I have understood with standard Unix based distro
> > deliverables is that there are standards (too many of them ;) to choose
> > from...
> > If we know what we are delivering then package management becomes very
> > easy...
> > Infact, you could check out Crux (http://www.crux.nu/), they use simple
> > .tgz based packages.
> 
> I don't see too many types of package management systems.  The way I see
> it, the primary three are RPM, DEB, and TGZ.  Beyond that, there're
> things like Portage.
> 
> The thing is, package management does not stop at package format.  It
> goes into how to add, remove, and maintain that package once it is on
> your system.  THAT is where the problems lie.  Anyone who's been stuck
> in RPM dependency hell is all too familiar with this.

I now that too well ;) And the strange thing is, deb does do better, but
that's it. It doesn't solve the problem. Let me give you a simple
example, one I haven't solved for the build guide...
Take ffcall, how does one detect it's version? The only thing you have
is to use the package managers data, You will run into trouble if ffcall
is installed from source... there is no way to track the correct
version.

> 
> > Why a live system? Why not a installable?
> > Dunno, but I guess with todays 700Mb CDs, it would be possible to deliver
> > both a live system as well as installables...
> 
> One of our goals is to be able to use the installation CD as a recovery
> disk, with a live system on it.  So, we need a small live system, and
> the installation files.  With careful design, good compression, and
> smart choices, one could fit everything neatly into one ISO.  It could
> be a tight fit, but that's where it becomes necessary to decide what is
> required for a live rescue system.  Mac OS is an excellent example of a
> good setup.

This is exactly why I suggested a three CD set. The first CD should be a
rescue CD too. And what I had in mind, but I guess it didn't come across
I think every CD should hold the source for every binary it has. Have
you ever tried to find the source of a binary on a RedHat or SuSE CD...
GNUstep is a developers system. Most coders use the code of others for a
start, so provide the code in a easy manner. Place it near the binaries.


> 
> > Server would probably be required for creating a central repository, that
> > which could hold the source for *all* GNUStep related stuff (base system,
> > library extensions, apps, misc stuff) in one place and people could use a
> > ports/CVS/rsync/<anyother_sync_app> to update their sources/binaries by
> > running a simple command or clicking a button in a GUI app...
> 
> This almost sounds like too many cooks in the kitchen.  Plus, there's
> also the potential for unmaintained, old versions of dead projects'
> software remaining there, and generally becoming a place full of
> questionable use.
> 
> Honestly, I'd much rather see a snippet of a script available from, say,
> gnustep.org, which you can put on your web server, which would submit
> your link back to, say, gnustep.net, with your project name, download
> link, etc.  When you update something, run the script, and it submits
> the new info.  Just a rough thought.  But central repositories for so
> many different things could become a nightmare to maintain.


I agree! Code may be scattered across the Internet, aslong as there is a
single source that holds the links... On the other hand a mirror might
be handy for code that is suddenly orphaned or if the server gets pulled
of the net.

Dennis

> 
> --
> 
> Tim Harrison
> tim@linuxstep.org
> http://www.linuxstep.org/
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://mail.gnu.org/mailman/listinfo/discuss-gnustep