Matt: > If libsexy has already been ARC'd then the package name should have > already been registered. Therefore I'd leave it in it's own package.
I did a search on sac.eng, and also through my own archives, and I don't see any ARC case relating to libsexy yet. I think this addition needs to be ARC'ed before we add it to Nevada. > If the package name has not been registered yet, then including it in > SUNWgnome-panel is fine, but I'm guessing this would be seen as a new > interface for SUNWgnome-panel package, and would need to be mentioned > quoting the original libsexy arc case in the GNOME 2.24 arc materials. Incorrect. The purpose of the GNOME 2.24 Umbrella ARC case is to discuss changes to Committed interfaces, and minor changes that were not otherwise ARC'ed. It is common for non-Umbrella ARC cases to mention changes to packages like SUNWgnome-panel if the ARC case is going to modify that package. One example is when we added the OTR module to the gaim packages: http://sac.eng.sun.com/arc/LSARC/2006/685/proposal.txt > Although at the end of the day, my preference would be to leave it on > it's own, I'm > not a fan of bundling loads of libraries into single packages, I'd much > prefer if they > were out on their own..... I think it is more important to make some effort to be consistent. I understand the value of putting various GNOME dependencies in separate packages, since other non-GNOME things might want to make use of them. So, in other words, it makes sense that libraries like libgcrypt or D-Bus is in a separate package. However, things that are used internally only by GNOME don't really make sense to belong in their own packages. Historically we have put more private packages into a bundled package. Since the long-term plan for this library is that it will go away, I don't see the value in adding a temporary package. Brian
