Glad to see interest in install/packaging

[Morey Hubin <mhubin icd teradyne com>]

     GPP'ers,

     Glad to see the concerted effort around packaging and installation
for Gnome.  I can completely agree with the value of a GPP having built
Gnome 3 times per 3 different platforms (2 Solaris's and Slackware).
It was a beast to build and even more painfull to upgrade source and
rebuild.  I'm sure we can make it easier.

     I'd like to volunteer on the GPP project.  I'm a release engineer
in Boston with a bit of free time and lots of experience in releasing
large devel projects.  I've been a Slackware developer for a long time
but my real specialty is Solaris OS config and install packages so I
can help bring that with me.

     Well down to buisness...

     I have a few ideas and this mailing list is the best place to
air them.  Keep in mind that I am not on any other Gnome mailing list
so if I propose things that already exist, go easy on me :)

     Some of these are about a hard installer app, others are about
devising an install standard for Gnome.  The two are tightly wound
together.

      ) A standard install path that everyone can use universally.
        I setup machines so /usr/gnome is a symlink to the actuall
        Gnome install.  That way I can burn in library paths using
        the linkers -R/usr/gnome/lib (or equivalent for your OS)
        and not have to worry about setting LD_LIBRARY_PATH at runtime.

      ) To prevent a chicken and egg argument I would like to create
        a Perl based Gnome install manager (GIM) that in no way relies
        on Gnome components to run.  I see a PerlTK GUI and an alternate
        silent install control language (really simple syntax) that
        manages the installation of kits.  It may not be as beautiful
        as other Gnome apps but it will be portable and easy to edit.

        The key is to identify the common needs for most native install
        managers ( rpm's, tgz's, Solaris pkg's, dpkg's, ...) and devise
        a GIM Virtual Interface (VI).  Aka, a fancy name for a set of
        functions that the GIM needs in your Perl module.

        Ex:  To install RPM's you write a perl module that knows how
             handle an RPM and also contains the functions we define.
             From then on the GIM will be able to manage the install of
             any RPM.

             If you want to install Solaris packages then you write a
             module and the GIM does the rest.

        With a little extra effort we could probably add to the VI
        finctions that allow us to work both ways and make new packages
        automatically.  It's really straight forward.


      ) A standard path to source that developers can use with GDB.
        GDB expects to find source in the same place it was built.
        If it doesn't then is asks the user to supply the correct path.
        This can get annoying for large projects.  If all debuggable
        builds take place under /usr/gnome_source then developers can
        setup a /usr/gnome_source symlink to thier download area and
        GDB away.

        This does mean that any build machines will have to mount build
        space under /usr/gnome_source.
        The debugger knows the absolute path to the source so there's
        no way to use symlinks to fake the path to the debug build.


      ) We sort the list of packages into classes like:
          Core Libs   (stuff heavliy depended upon by user apps)
          Gnome Libs  (stuff needed to run the Gnome App Environment)
          Extra Libs  (stuff no so heavily depended on)

          Gnome Run   (panel, menu applets ... )
          User Apps   (Useable even if you are not running gnome)
          ... User Apps can be subdivided by what they do ...

      ) Release and Debuggable versions of packages wherever possible.

    Thats plenty for now...

  Morey Hubin