Re: Glad to see interest in install/packaging

[David Elliott <dfe infinite-internet net>]

Morey Hubin wrote:

>      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 certainly hope so!

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

Good to see someone with more POSIX experience than just Linux.

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

On Linux at least we ought to follow the filesystem standard. Stable
installed packages should have prefix=/usr, all configuration goes in /etc
or for lots of files in a directory under etc.

However, development releases shouldn't screw with a stable gnome config, so
the best place for those is probably in /opt/something.  Perhaps something
like /opt/gnome-20010429 for CVS snapshot builds.  The key is to not lock in
any one prefix.  I believe KDE still defaults to /opt/kde, but the RH7.1
packages of it install directly into /usr (where a stable release should
really be on a RedHat system).

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

I don't see adding a dependency on TK as a good thing.  Why not use the
latest stable GTK?  It's not really a chicken and egg problem.  The latest
stable GTK is pretty much standard issue on Linux now and building GLIB and
GTK is a fairly trivial task.

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

This does not really sound like packaging components, but rather
distributing them.  I don't think this project is trying to compete with
red-carpet or apt-get.

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

This does not sound trivial at all.  It sounds like you want to rewrite
apt-get and make it cross platform.

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

Now this is a very valid point.  I would suggest $prefix/src/package-name.
That is something like /usr/src/gnome-core-1.4.0 or for devel stuff
/opt/gnome-20010429/src/gnome-core-1.5.0  (assuming 1.5.0 is the devel
version and the prefix is /opt/gnome-20010429).

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

Hmm, that sounds like a real fuck to me.  Is there any sane way around this?

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

I believe that for the most part this is already done.  Really the more
fine-grained control the better.  But then again, don't overdo it.

>
>       ) Release and Debuggable versions of packages wherever possible.
>

Release early, release often.  Preferably have a high-power compiling
machine or farm that automatically builds and packages CVS every night.

>
>     Thats plenty for now...
>
>   Morey Hubin

-Dave