John: > Support for an interface has no barring on the EOF process. > For Committed and Uncommitted interfaces one must go through > the EOF process. For Volatile interfaces it is a little bit > more difficult to discern when to follow the process and not. > For example, if the security team were to remove OpenSSL they > would need to go through the EOF process because they have > so many projects depending upon them. If sfw decided to > remove the animate binary from /usr/sfw then they could > probably do so without the process. > > Which interface(s) are you concerned about?
We are talking about the libsexy package names, SUNWlibsexy and SUNWsexy-python. Package names are typically defined to be Uncommitted. These package names are defined in the Compiz LSARC case (2008/115). We know the GNOME community plans to merge libsexy's library functionality into GTK+, and the libsexy library will eventually go away. So, we have been discussing whether it would make more sense to put libsexy in a package like SUNWgnome-base-libs. This way we do not have to remove the Uncommitted SUNWlibsexy and SUNWsexy-python packages later. The reason our team tends to bundle multiple modules in generic package names like SUNWgnome-media, or SUNWgnome-base-libs because this gives us some flexibility to add/remove content from the packages without affecting package names. Since package names are typically Uncommitted, this means we would need to go through the EOL/EOF process if we remove the package, or if we replace one module with another (like replacing gnome-cd with sound-juicer). Isn't this correct? If we decide to put libsexy modules in SUNWgnome-base-libs or some other generic package, then do we need to do anything to inform ARC that we will not be adding the package names as specified in the LSARC 2008/115 case? Your thoughts? Brian
