Re: PROPOSAL: "Staging Areas"

[Jim Pick <jim@jimpick.com>]

Mitch Blevins <mblevin@mindspring.com> writes:

> In foo.debian-gtk-gnome, Jim Pick wrote:
> > Hi,
> > [snip excellent staging-area proposal] 
> 
> How will we handle those packages with dependencies on several
> different libraries (that are unstable).
> 
> For example: we have a staging-glib-1.1.20 and a staging-gnome-0.99.72.
> Are these staging branches released simultaneously?
> If so, is there really a need to name the staging area after a particular
> package?  Maybe we could just have a staging-really-unstable that contained
> all the gnome-glib-gtk-other stuff?
> 
> It seems that we have almost a heirarchy here. (or at least a directed graph)
> 
>             ---> libgtk ------
>            /                  \
> libgnome --                    ---> libglib
>            \                  /
> 	    ---> gdk-imlib ---
> 
> where a package can directly depend on one or more of the above four,
> and will always indirectly depend on the packages downstream of the
> arrowheads shown.
> 
> When a staging area is released, all staging areas upstream of of the
> released one must be released simultaneously, and must have been
> compiled with the downstream versions.
> 
> The only advantage I see of having these staging areas separate is
> that you can save trouble by only releasing the packages in (for example)
> stage-libgnome-x.x when the gnomelibs bump a version, but the gtklibs
> stay the same.
> 
> However, you introduce complexity by having some packages that directly
> depend on both libgtk and gdk-imlib.  Which staging-area should they
> go into?  Can we ensure that we don't have overlapping releases of
> these two libraries?  Is it dangerous to have a package in more than
> on staging area at once (one gets recompiled with a new lib, and another
> doesn't...)?
> 
> Thoughts?

My example ("staging-glib-1.1.20") wasn't a really good one.

What we do for the gtk/glib/imlib/gnome stuff is pick a set of core
packages that we want to rebuild everything for.  For example,
the latest Gnome stuff is based on:

  glib 1.1.15
  gtk+ 1.1.15
  imlib 1.9.3 (possibly a snapshot release, you know how they are
               with version numbers)
  orbit 0.3.98
  gnome-libs 0.99.8.1

I don't know what a description name for that would be.  Perhaps
"stagingarea-gnome-0.99.8" would be the best name to describe all the
libraries as a group.

Or maybe "stagingarea-still-conspicuously-skillful-cow".  :-)

Maybe we should use "stage-" instead of "staging-" or "stagingarea-"?

Maybe there's a better synonym for "staging area"?

We could also just call it something non-descriptive, such as
"stage-gnome-gtk-a".

In many cases, the need to do the staging area thing is going to be
due to a single incompatible library.  The glibc 2.1 transition is
a good example.  We need to recompile all the C++ applications.  So
we might just call it "stage-glibc-2.1".

Another example is the giflib/libungif, which we should package.  All
the applications which use giflib/libungif 3.0 will need to be
recompiled for 4.0 (or we'll risk mixing libs).  We could call that
"stage-giflib-4.0".

Anyways, all this naming stuff can be argued about on the mailing
lists.  We might just adopt even more codenames...

It gets a wee bit messy when a package ends up in more than one
staging area at once.  That's not the biggest problem, because the
staging areas won't be released at the same time, so there will be
plenty of opportunity to update the packages in the later released
staging areas.

Cheers,

 - Jim