GNOME.org
 

[Fwd: Glad to see interest in install/packaging]

Forwarding this because I believe Morey meant to hit Reply-All and not
Reply.

-Dave
--- Begin Message --- 
On Sun, 29 Apr 2001, David Elliott wrote:

  Just to clarify, I was thinking ahead.  To setup an automated build on
a build farm you have to know a little about the product you're building.
Setting the ground rules about what you can guarantee on the user's
systems reduces the complexity of the automated build environment.

  I'm concerned with source tree setup, package creation and package
management.  Less about PC based hardware.  My only contribution far
as build hardware is that compilations are RAM and disk/IO intensive
operations.  A dual or quad cpu machine with moderate cpu speed and a
fast SCSI raid.  I don't know any PC brand names to recommend.

> Morey Hubin wrote:
> 
> >
> >       ) 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).

  That's fine.  Linux distributions glob everything into /usr/bin.  I can't
say I'm a fan of that but it works.  If you overwrite something critical to
your system then get out the Red Hat CD and begin re-installing right now.
Me, I just /bin/rm -rf /usr/gnome-build2 and all errant bins are forgiven.

  Using /usr/bin is extremely dangerous on networked Solaris boxes.  Solaris
provides thier own versions of tar, sed, libintl.a and other GNU replacements
that are incompatible with the originals.  Overwriting one of these can be
fatal.  In addition Sol uses slices for /usr and /opt leaving the bulk of the
disk space under /home/<nodename>.  Pre-Gnome configured systems don't have
the space in /opt (or /usr) for 250Mb+ of new binaries.

  I'm partial to the /opt/gnome-MMDDYY for snapshot builds.  Again we should
look into choosing a static path to serve as a reference point for the gnome
run-time.  Say /opt/gnome-devel -> /opt/gnome-20013322 so that we can burn in
libpaths to /opt/gnome-devel and still allow devel to change quickly.  This
has a large effect on the build environment so that is why I harp on it.
I can explain this in detail some other time if anyone cares to read it.

  Also keep in mind that ~/.gnome, ~/.gnome_private and ~/.enlightenment
keep absolute paths to themes, libs and other apps.  Changing from
/opt/gnome-1111 to /opt/gnome-2222 means that most of your user config
is gone and enlightenment stop working.  The enlightenment binary actually
remembers the path where it was installed.  If you move it then it ceases
to work.  It is not the only exec that does this but it is the most obvious.

> 
> >
> >       ) 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.
>
  PerlTK is a simple downloadable perl module.  Building GLIB and GTK is not
something non-Linux beta testers can do easliy.  Documentation people either.
For you and I it's a piece of cake.  The rest of the world is not so savy.
Most of the people I work with have never heard of configure/autoconf, do not
have root access to thier machines and do not know about compiling packages.

  Anyway when I heard about beta testers I thought about having a simple
Perl download manager.  Linux is the only OS that delivers glib&gtk natively.
My thought was that we could piece together a simple download tool that
stores the names of mirrors.  This whole thing is off topic.

> 
> >
> >         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.
>
 +++++++++ Off topic so skip to next question if not interested +++++++++++
  No more than Slackware's rough ncurses install competes with Red Hat's.
Your right though, it is off topic.  My companies "beta testers" are generally
well organized and thurough people who are fairly helpless at a UNIX prompt.
A simple download&install manager may increase your beta tester population.

> 
> >
> >         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.
> 
 +++++++++ Off topic so skip to next question if not interested +++++++++++
  I'm well versed in perl modules and would probably take about 2 weeks
to code and test.  I'm not boasting, they are that easy to write.  I've
coded enough installations to know most of the basic needs.  If you know
the list of files and the package dependencies then creating the tgz, rpm,
dpkg or Sol pkg is routine.  I'm not an expert on rpm's but I'm learning
fast.

> >
> >       ) 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).
> 
  To expand a little I have /usr/gnome_source as the root of the source
tree followed by, [ stable/ || unstable/ || gnu/ || contrib/ || scripts//]
then the packages below that.  Contrib/ contains jade, Berkeley DB, libjpeg
Perl5.6 (for glade) and other non-Gnome buildables.

> >
> >         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?
> 
  Not that bad really.  In my work environment compute servers are special
and we can do non-standard things to them.  The ends justify the means :)
As long as the configuration is reproducable and well documented we can
make changes to improve the environment for developers.

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

  You can probably optimize build server time by rebuilding core libraries
less frequently than apps.  Thats why I wanted to identify them.  The more
dependencies, the less often it should be rebuilt.  Changes to low level
libs tend to be more invasive, take longer to perfect and are generally
more dangerous inbetween stable builds.
> 
> >
> >       ) 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.
> 
  We build 23 versions of a 4+ million line software package 6 days a week.
I am a firm believer in automatic turnover and publishing as much as possible.
> >
> >     Thats plenty for now...
> >
> >   Morey Hubin
> 
> -Dave
> 
> 

  G'night all
  Morey

--- End Message ---
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]