Amit Gupta wrote: > > Do find the updated ARC case attached. The summary of the changes is as > follows: > > - updated the file layout as per Darren's suggestion.
jv01: The layout is now inconsistent with respect to versioning support. Note how various parts are versioned to 'collectd4' but other parts (under /usr/share/man and /usr/include) are not. That's the worst of both worlds, as it cannot support multiple collectd versions but pollutes the namespace with a partial attempt. The key decision to make is whether it is likely that collectd 4.x and [a future] collectd 5.x may both be needed in the same release of Solaris. There is no blanket answer to that unfortunately. At best, with enough familiarity with the upstream community, their future direction and the future direction of other components which use collectd, you can make an educated prediction. Given the upstream community has stated their major releases are incompatible it suggests coexistence might be needed. AFAIK there is no version 5 yet but looking back, looks like they still support 3.x (in maintenance mode) along with 4.x because the two are incompatible (http://collectd.org/download.shtml), so it is not unreasonable to imagine 4.x and 5.x may have a similar coexistence. On the down side, versioning always adds a bit of clutter and inconvenience unless needed. Think about it and decide whether to support collectd version coexistence or not. If anyone who is interested in collectd has a preference, speak up now. Once you decide, make the layout fully reflect the decision. Either it needs to allow coexistence everywhere, or not. jv02: Iff version coexistence is chosen, I was hoping for ARC members to have opinions on $COMPONENT$VERSION/* vs. $COMPONENT/$VERSION/* directory naming (see earlier email). If there are no opinions, project team can do as they wish. > - included collectdmon as suggested. In general it is unnecessary to deliver functionality which duplicates what smf provides. e.g. we don't deliver init.d files from upstream components just because they exist, given on Solaris smf takes care of it. collectdmon seems to fall in the same category. That said I don't have a strong opinion there, if you feel there is a customer benefit to delivering it, then ok. jv03: However, if you do, then document how the collectd smf service and collectdmon can (and can't) interact. In particular, in what ways can things go confusingly wrong if customer attempts to use both? The collectdmon man page is a good place to insert this information. > I am not sure as yet if we need to deliver only one collectd package i.e > SUNWcollectd?. As I mentioned earlier, I have followed the lead of > apache, lighttpd. mysql etc. all of which deliver a separate root and > usr package. Since you are integrating into sfw you will be required to integrate both usr and root packages. We also know they'll get renamed several times in ways outside of the project team control, so no point worrying about it until OpenSolaris gets its ARC act together. Call them Volatile, if you like. -- Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems
