Re: Package managment idea...

[Matthew Berg <wdomburg pce net>]

> Anyway, this has nothing to do with Gnome and is clearly outside the scope
> of the Gnome project. The proof is that any package system will have to
> work in a no-GUI environment.
> 
> Havoc

I would generally agree that package management is outside the realm of
GNOME, which is primarily a GUI environment, but it is also a usability
project.

GNOME is a cross-platform project, and I think that a common interface
for package management would be a big win for the project.

Also keep in mind that there is already binary compatibility on many
platforms, and there are more coming.  By keeping with the tradition of
repackaging for every package subsystem, we are essentially throwing
away a large portion of this advantage. 

Would you rather see FooApplication.i386.rpm, FooApplication.i386.deb,
FooApplication.i386.slp, FooApplication.i386.custom and whatever they
call the packages on Unixware, Solaris x86, OpenBSD, FreeBSD, and BSDI;
or would you rather see a single package for each hardware platform?

I suppose this could be done by extending Alien to handle a wider
variety of format.  I haven't looked at the code for this yet, so I'm
not sure how extensible its design is.  I think a modular architecture
is key to it being successful.  

The two routes I see are either using the glib plugin architecture, or
by using corba.  

The glib approach has the advantage of not being tied to the overhead of
ORBit running.  Maybe the best way would be to implement low-level using
glib modules, with CORBA wrappers.

This way you would achieve the lower overhead of the glib approach for
those who aren't interested in remote management, but leave the option
open for those of us who are.

As I mentioned in my post to Jason, I was thinking about the problems of
relocation, which have traditionally been left to the application
programmer to deal with, and have all too often been hard-coded into the
application, controlled by environmental variables, or buried in
configuration files.  All of these approaches are entirely too messy for
my tastes.

What about maintaining this information in $PREFIX/share/apps, as the
system menu info is kept in GNOME.  That way you could create a simple
library applications could call on for bare bones configuration
information.

But I digress - back to the origional point - 

Yes, these things techinically don't fall under the origional scope of
GNOME, but they are nonetheless issues that the developers have to deal
with.  And even more importantly, have to deal with on a wide variety of
systems.

Technically, it could be argues that memory management routines such as
GLIB don't belong in a desktop project, or a CORBA implementation.  If
you ignore the fact that in bringing a cohesive application framework to
life, you have to create where there only exists a vacuum to be filled.

Tidings of Comfort and Joy,  

  Matthew Berg :)