I'll echo Jim's comments in the SQLite case about calling everything
Volatile.  It's really not appropriate, especially since these are
components that exist specifically for other projects to build on top of.
Given that these libraries are themselves built on top of the C versions of
the same libraries to which we're assigning a "Committed" label, I'd expect
that these were at least Uncommitted, if not Committed.

Can you provide some rationale for why you expect these interfaces would
need to change incompatibly and without warning in patches?  Or, better,
why they're actually highly unlikely to change incompatibly at all, and
thus could be Committed?  :)

You're also specifying everything by pathname, which is inappropriate.  For
instance, the .pc files and the directory they live in are Private
implementation details, but the base name of the files are the public
interfaces that people will use to pass to pkg-config(1).  That's how they
should be described.

>         /usr/lib/libsigc-2.0.so                             Volatile       
>         /usr/lib/libcairomm-1.0.so                          Volatile
>         /usr/lib/libglibmm-2.4.so                           Volatile          
>        
>         /usr/liblibatkmm-1.6.so                             Volatile
>         /usr/lib/libgtkmm-2.4.so                            Volatile
>         /usr/lib/libgdkmm-2.4.so                            Volatile
>         /usr/lib/libpangomm-1.4.so                          Volatile

Are these libraries correctly versioned as described in the libraries best
practices document?  Do they have their private symbols properly scoped?

>         /usr/lib/libglibmm_generate_extra_defs-2.4.so       Volatile

Does anyone ever need to link to this library specifically?  This seems
like a very private implementation detail that should either be a filter
library or simply not exist on Solaris.

>         /usr/lib/glibmm-2.4/proc/gmmproc                    Volatile    

What goes here and why is it Public?

>         /usr/lib/glibmm-2.4/include/glibmmconfig.h          Volatile          
>   
>         /usr/lib/sigc++-2.0/include/sigc++config.h          Volatile

Why do we have Public header files under /usr/lib?  Such things tend to be
Private.

>         /usr/include/sigc++-2.0                             Volatile         
> Directory for hearder files
>         /usr/include/cairomm-1.0                          Volatile         
> Directory for header files
>         /usr/include/glibmm-2.4/glibmm                      Volatile         
> Header files directory
>         /usr/include/glibmm-2.4/glibmm_generate_extra_defs  Volatile         
> Header files directory

These two directories seem rather private, too.

>         /usr/include/atkmm-1.6                              Volatile         
> Directory for atkmm headfiles
>         /usr/include/gtkmm-2.4                              Volatile         
> Directory for pangomm headfiles
>         /usr/include/pangomm-1.4                            Volatile         
> Directory for gdkmm headfiles 
>         /usr/demo/jds/bin/gtkmm-demo                        Volatile

Here's a general question to the JDS folks -- is it worth making any of
these header directories Public at all?  It seems that pretty much the only
way people know where these things are is through pkg-config(1).  Or are
these names, complete with version numbers, stable enough that it's what
people actually code to?  For that matter, are the version numbers of the
.pc files stable at all?

Danek

Reply via email to