Brian Cameron wrote: > > 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. > As these packages have already been ARC'd and therefore registered. Would the removal of these packages require an ARC EOL/EOF process either way ? So therefore simply integrating them as is would be the simplest solution.
If not, then by all means include them in SUNWgnome-panel, however depending on how package dependencies resolve, this could have an impact on where SUNWgnome-panel would appear in the build sequence of GNOME, e.g. if another application requires libsexy and libsexy were integrated in the panel that component would have a dependency set for SUNWgnome-panel, so therefore the entire panel package would need to be built etc before it. Just need to make sure all dependencies are set correctly. Whatever is the easiest/quickest solution then that's my vote. cheers Matt > 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 >
