Roy Lyseng wrote: > > As a matter of fact, the ARC case is already filed as LSARC/2007/385. > > 1. Where shall we put the binaries and libraries? I see that some > similar tools are put in /usr/bin, some are put in /usr/sfw, and some > have their own /usr subdirectories, such as /usr/apache2.
Please tell us more about what files this project is delivering. Is it only shared libraries? CLIs? Daemons? Something else, all of the above? Take a look at the locations as delivered by the default make install as well as how all these files are delivered by a few Linux distros. Let the list know this info and we can then look at where it should go in OpenSolaris. > 3. Packaging > > Ideally, each component would go into their designated package, but for > simplicity I am thinking about putting the server and all clients into > one package. Opinions? One benefit of packaging is making sure dependencies make sense and are met. For example a ruby API doesn't do much good if there is no ruby. I recommend you package each language API in its own package, with proper dependencies. It's a bit more work up front for you, but later allows the tools to ensure a coherent system is in place. Look at other distributions for insight into what might've worked (or not) for others. For instance, on my debian box here I see they have a "php5-memcache" package and it depends on "php5-common". The C API is so universal that you might just include it in the server package, maybe. > 4. Bugtraq account. > > We require a bugtraq account for the product, and it seems that it will be > > product=solaris category=utility subcategory=memcached Either that or solaris/library/memcached. The same exercise to solve your point #1 will probably point in the right direction for this as well. -- Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems
