* Roy Lyseng <Roy.Lyseng at sun.com> [2007-09-24 13:41]: > Hi, > > I am writing the ARC case for memcached, and I need some guidance on > file names, components to include and packages. > > 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. > > What is the recommended practice for this? /usr/sfw is an obsolete tree; no new packages should deliver content there.
If a developer would typically run a private instance of memcached, then /usr/bin would be appropriate; otherwise, daemons live in /usr/lib. (The SMF service description would be how an authorized user activates the service.) > 2. Components. > > It is obvious that we include the memcached server as a component, but > what about the client libraries? My thought on this is that a memcached > server without a client library is pretty useless, so I would like to > include some of the important clients in the ARC case. > > The list of clients that I suggest are: > > Perl API > PHP API - PECL > Ruby API > Java API > libmemcache (C API) > pgmemcache > > Not sure about the last one - and it may just as well belong in Postgres. At present, no consolidation delivers a Ruby install. I would expect the others (although I, too, don't know much about pgmemcache). > 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? Deployers might prefer to minimize based on the languages they install, which would argue for 4+ packages. Certainly the C API should be bundled with the package delivering memcached. - Stephen -- sch at sun.com http://blogs.sun.com/sch/
