New idea (was: Re: Package managment idea...)

["Jason Nordwick" <nordwick xcf berkeley edu>]

I had an idea in the shower today:  What it each Gnome compliant program
also
shipped with a binary/script called <prog>-gnome-init.  This might just be a
link to the binary that inspects argv[0], but could be seperate.  On startup
of Gnome, it would look for all *-gnome-init executables in its path and
execute them.  They could then add whatever icons are needed to the desktop,
start-menu, blah, blah, blah.

There could even be argument to it: one for first time, one for each
session, one for shutdown, one for uninstall.

To make the process faster at Gnome startup, you could keep a record of ones
that you have already called, and check to see if the mtime is since them,
so for a program to get that run again (let say to activate a menu to ask if
you want to associate a file type with a/the program), it would simple set
mtime to be the current time, then, next time gnome looks at the
<prog>-gnome-init executable it would run it.

The benefits are: the native package system of the system does not have to
know about it;  it is a good way to add program to anything needed, such as
'start menu' (for lack of a better term), desktop, file associating, root
menu, and much more; third, it is extensible and more calls and things can
be added and the system wide packing model will not need to be changed.

I know that idea it not fully thought out, but I think that it is an okay
start for an idea.

Any comments, suggestions?

(yes I realize that there is overlap between the window managers startup
file and some of these ideas, but that can all be fleshed out later).

If there is enough interest, when I get off vacation (Another week), I will
made a small implementation, if wanted.

>
>I don't want to get away from it, but there is no way to write a package
>manager for tarballs. A generic GUI simply can't handle them because build
>setups are not predictable and there's no dependency information. End of
>story. tarballs are for command-line users unless they are packages that
>happen to be in tar.gz format (like dpkg and slp).
>

Hmm... the BSD ports mechanism seems to deal with them.  But that is kinda
platform specific.  It has sort of a two level method.  First, it relies on
the programs own configuration system (such as GNU Configure), second it
applies appropriate patches for FreeBSD systems that the configure scripts
may have missed or that provide better performace (such as madvise).  These
patch scripts are getting more obviated as people get better at building
cross platform code.  Dependency information is coded by the person who
setup the port.  What a port basically does is compile a package, then use
pkg_add to add it to the system.

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

I agree that a packaging system is beyond the scope of Gnome, but just an
FYI, there is a X-capable/CLI prompting system distributed on all FreeBSD
systems.  Someone has yet to write the X interface, but you call the program
from a shell script telling it what kind of menu and what the entries are,
and after the user decided, it tells you what he picked.  This is used for
prompting for information while building a port (although not many people
are currently using it, but more are starting it seems -- for those FreeBSD
people, look at the Ghostscript installs, it uses the combo list box). So a
prompting system can be run under both X, CLI, and curses.  Its really kinda
cool.

>Havoc

-jay