Re: PROPOSAL: "Staging Areas"
In foo.debian-gtk-gnome, Jim Pick wrote:
> [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
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