Question of HP updates that depend on new packages
marlowsd at gmail.com
Mon Aug 17 10:29:14 EDT 2009
On 17/08/2009 14:10, Duncan Coutts wrote:
> A requirement of packages in the platform is that all dependencies of
> packages also be in the platform (excluding C libs).
> When an updated version of an existing platform package includes
> dependencies on packages that are currently outside the platform we must
> decide if those packages are to be added to the platform (or if we must
> stick with the older version of the package).
> Sometimes this will be trivial, such as if a package splits in two but
> keeps essentially the same API and module namespace. Sometimes it would
> means pulling in new packages. Normally new packages should go through
> the standard process for adding packages
> [Note: currently, the HP steering committee is nearly ready to present a
> draft of the procedure for adding new packages.]
> The case of the OpenGL 2.2.x -> 2.3 update covers both cases above. That
> is it includes straightforward package splits and also new packages.
> The last HP release included OpenGL-22.214.171.124. The latest version on
> hackage is OpenGL-126.96.36.199.
> OpenGL-2.2.x depends on the base package.
> OpenGL-188.8.131.52 depends on these extra packages:
> The first two are relatively straightforward. The OpenGL package has
> modules in the namespace Graphics.Rendering.OpenGL. The OpenGLRaw and
> GLURaw add modules in the namespaces Graphics.Rendering.OpenGL.Raw and
> Graphics.Rendering.GLU.Raw. One can easily class these new packages as
> merely split from the OpenGL package and this does not need much review.
> The other three packages are:
> package: ObjectName
> modules: Data.ObjectName
> package: StateVar
> modules: Data.StateVar
> package: Tensor
> modules: Data.Tensor
> These add new modules in the common Data.* namespace, indicating that
> they are intended for re-use more widely by other packages.
> The release team should not make a decision on these three packages on
> its own. We wish to refer these packages to the libraries list for a
> In particular the libraries list should decide if these new packages
> should be rubber stamped because they are new dependencies of a package
> already in the platform, or if the new packages should go through the
> standard review process for adding packages.
We should consider these 3 packages as candidates for inclusion in the
platform, and deal with them as we would other candidates; i.e. subject
them to the proposal/review process (which I know is in the process of
In this case, we are in the slightly unfortunate position that if the
packages are not accepted for inclusion, and even in the absence of any
decision at all, the platform will be unable to ship the latest version
In the event that the new packages were rejected, then I imagine OpenGL
would either have to re-absorb those modules (as hidden modules), or the
platform would have to drop OpenGL since the old version would be
unmaintained. I'm fairly confident it wouldn't come to that, though.
Personally, I doubt the new packages would be acceptable, at least in
their current form. e.g. ObjectName is a very general term for a
library that seems to have quite specific functionality.
More information about the Libraries