Great reading, it seems like most major Linux distributions are following the Filesystem Hierarchy Standard: http://www.pathname.com/fhs/
In the light of Project Indiana, is that something we should follow? Jan S Brandorr wrote: > Read through this thread for a discussion of MySQL installation paths. > (Linux user group) > http://www.nylug.org/pipermail/nylug-talk/2007-October/035659.html > > On 10/3/07, Jan S Berg <Jan.Berg at sun.com> wrote: >> Brandorr wrote: >>> On 10/4/07, Jan S Berg <Jan.Berg at sun.com> wrote: >>> >>>> Brandorr wrote: >>>> >>>>> If you haven't gotten an answer yet, I think the standard is to have a >>>>> /usr/mysql5/ >>>>> >>>> Ok, thanks. Have proposed in the ARC draft to use /usr/mysql/5.0, >>>> as done by Apache, Ruby and Postgres. >>>> >>> I really don't thing you will want the ".0" Basically it's either >>> /usr/mysql4 or /usr/mysql5. >>> >> But it seems like Apache, Ruby and Postgres are using >> /usr/<productname>/<versionnumber> ? >> (Postgres has /usr/postgres/8.2/ f.ex) Apache has a apache and apache2, >> but they also have a version number after /usr/apache2/<version> >> >> Jan S >>>> Jan S >>>> >>>> >>>>> On 9/26/07, Jan S Berg <Jan.Berg at sun.com> wrote: >>>>> >>>>>> An update... >>>>>> >>>>>> Jan S Berg wrote: >>>>>> >>>>>>> Thanks for the input, I have posted also on the database-discuss list. >>>>>>> >>>>>>> Are there defaults for where to put application configuration files? >>>>>>> >>>>>> It seems like there could be three different approaches: >>>>>> -Apache puts it under /etc/apache >>>>>> -MySQL in Fedora/Red Hat puts a default under /etc >>>>>> -PostgreSQL does not have default, but gives a sample under >>>>>> /usr/postgres/8.2/etc >>>>>> >>>>>> I guess this is related to another discussion about where to binaries >>>>>> (directly under /usr/bin or /usr/mysql/5.0/bin) ? >>>>>> >>>>>> >>>>>>> And also for MySQL there might be a default for where to put database >>>>>>> logfiles and datafiles. Since datafiles for a database could be rather >>>>>>> big, a default location might be a bad idea. >>>>>>> >>>>>>> And for packaging, should it be available as one package, or is it >>>>>>> standard to offer different packages for client, server, docs, source, >>>>>>> etc? >>>>>>> >>>>>> Propose to use one package for the server and separate packages for >>>>>> clients, as it seems to be standard. >>>>>> >>>>>> Jan S >>>>>> >>>>>> >>>>>>> Jan S >>>>>>> >>>>>>> David.Comay at Sun.COM wrote: >>>>>>> >>>>>>>>> First we want to use studio12 as compiler, as that gives quite much >>>>>>>>> higher performance gain (using new compiler flags in studio12). >>>>>>>>> We would like databases to work as good as possible on Solaris, and >>>>>>>>> especially we would like to have performance numbers favorable over >>>>>>>>> Linux :) >>>>>>>>> I see that the compiler for webstack is studio11, is it possible to >>>>>>>>> upgrade to studio12? Or can we use studio12 for MySQL? >>>>>>>>> >>>>>>>> All OpenSolaris components are built with the standard Common Build >>>>>>>> Environment or CBE. At the moment, the C compilers used for this are >>>>>>>> Studio 11 (plus patches) and the bundled gcc 3.4.3. I'm not aware at >>>>>>>> the moment of a precise date for upgrading to Studio 12 although work >>>>>>>> is underway on evaluating it from regression and performance >>>>>>>> perspectives. >>>>>>>> >>>>>>>> The official Studio part of the CBE can be found internally via the >>>>>>>> following automount point >>>>>>>> >>>>>>>> /ws/onnv-tools/SUNWspro/SS11 >>>>>>>> >>>>>>>> or externally via >>>>>>>> >>>>>>>> >>>>>>>> http://opensolaris.org/os/community/tools/sun_studio_tools/sun_studio_11_tools/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Second, which MySQL components should be included? They have three >>>>>>>>> client components that all seems quite useful to include. This is >>>>>>>>> Connector/J for JDBC, Connector/ODBC for ODBC and a PHP client >>>>>>>>> library. >>>>>>>>> Should also any GUI tools be included? >>>>>>>>> >>>>>>>> I would recommend also asking the database-discuss at opensolaris.org >>>>>>>> community for their input too. >>>>>>>> >>>>>>>> dsc >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> webstack-discuss mailing list >>>>>>> webstack-discuss at opensolaris.org >>>>>>> http://mail.opensolaris.org/mailman/listinfo/webstack-discuss >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> webstack-discuss mailing list >>>>>> webstack-discuss at opensolaris.org >>>>>> http://mail.opensolaris.org/mailman/listinfo/webstack-discuss >>>>>> >>>>>> >>> >>> >> > >
