Brian, I wouldn't do an EOF case for this change. The biggest reason is because this has not been in a revenue release. Simply create package history files so that the appropriate thing happens when upgrading.
Thanks, John Brian Cameron wrote: > > 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
