Jedy: > libsexy has already been ARC'd so I guess the package name has already > been registered.
Oh, I see, this was ARC'ed along with Compiz and the package names are SUNWlibsexy and SUNWsexy-python. http://sac.sfbay/LSARC/2008/115/proposal.txt > Putting many libaries into one packages will redcuce the number of spec > files but will increase the build time and the difficaulty of updating > a single library. Leaving the library alone will introduce complicated > dependency and we have to maintain more spec files. ???Do we have any > policy to handle this situation? The advantage of lumping multiple modules into a single package is that it can help to avoid needing to go through the EOL/EOF process when something is removed. For example, we currently have libgweather in SUNWgnome-panel. If, in the future, libgweather were to go away, then we can remove it without affecting any package names. Since package names are normally "Uncommitted", if we have libgweather in its own separate package, then you need to go through the EOF process when it is removed. So, it is generally not a good idea to put something into a separate library if you know it is likely it will go away. Highly volatile or private libraries are typically the best candidates for libraries to be bundled into a multi-module package. On the other hand, libraries that are commonly used outside of the GNOME stack (e.g. dependencies such as GnuTLS or libexif) make better sense to have in separate packages. So, Jedy, we have two choices: 1. Submit an ARC FastTrack to specify that you plan to integrate these interfaces into a different package than was previously specified in the Compiz case. Then we could bundle it into SUNWgnome-base-libs or SUNWgnome-panel. 2. Add the new package specified in the Compiz ARC case with the understanding that you (or someone) will need to go through the ARC EOL/EOF process when we want to remove the package. Really #1 is less work since you have to give 1 years prior notification when you EOL/EOF. Avoiding the hassles of approach #2 was the motivation for multi-module packages. Brian
