How about if the PHP client is delivered in the PHP package ? That way, PHP developers have ready access to it.
Shanti Stephen Hahn wrote: > * 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 >
