Jyri Virkki wrote: > Amanda waite wrote: > >> I have a question for you, where would you install the SilverStripe >> files to? >> > > Under /usr somewhere for all the static content, config files under > /etc, runtime (if any) under /var. In other words follow standard > [Open]Solaris layout. >
Reading what you included below, by static content you mean PHP files right? What about any generated content? What about css, js and template files which might be customizable? I can see the logic that a PHP file is a binary all but in implementation but PHP files are provided as part of a structured web app layout, one that's often customisable, not just config wise, but also content wise. Anyway, these apps write directory specific config files such as .htaccess, there's never any guarantee that /usr will be writable and you can't put a directory specific .htaccess in /etc. You'd need to re-purpose the whole app. In this respect it looks as if Drupal is a little different to the likes of SilverStripe.(comment on what you included below). > I haven't tried SilverStripe so don't know if that'll work, but the > only reason it wouldn't work is if it doesn't have any static files > (e.g. it is all self-modifying code.. shudder!) > Why should we not do what Sriram suggests and what's done on Linux and drop the whole app in /var/www? The benefits would be great, everything in one place, and generally in sync with all the docs and blog entries on configuring and debugging. Following the standard [Open]Solaris layout doesn't seem to apply with these apps, as you point out this is something that's not been done yet and we can set a precedent here. The benefits of breaking out bits of the app into /usr seem to be outweighed by the level of complexity that that adds to the integration, complexity that opens the door for corner case issues that we'll constantly be fighting to fix. Amanda > Here's what I posted in sw-porters-discuss on April 17 wrt same > question for MediaWiki: > > > >> I favor delivering the static binaries (they may be written in PHP but >> that's an implementation detail) under /usr somewhere since that's >> where static binaries go, if possible. >> >> For an example take a look at the Drupal delivered in Web Stack repo: >> http://pkg.opensolaris.org/webstack/manifest/0/drupal%406.3%2C5.11-1%3A20090310T220655Z >> >> All the application files live under /usr/drupal/* >> Config file is under /etc/drupal/ (with a link from usr/drupal/sites) >> >> Drupal's layout made it very easy to make the clean partitioning work. >> Maybe some other apps make that harder to do than others though. I >> haven't tried it with MediaWiki. Something to explore. >> >> Finally, the package delivers /etc/apache2/2.2/samples-conf.d/drupal.conf >> containing a configuration ready to go for Apache 2.2. Note the config >> is dropped into samples-conf.d so user can link to it from conf.d as >> soon as they're ready to make the site go live. >> >> Another benefit here is that Drupal is not tied to apache2. If users >> want to use this drupal package with a different web server that'll >> work fine since the bits are in a generic location under /usr and /etc. >> >> Apache being common, it delivers samples-conf.d for apache2 as a >> nicety (see below) but doesn't in any way limit the package to be >> useful only for Apache. >> >> >> >> >>> Also would >>> the packaging contain each individual file in the source package or >>> bring down to the user machine the tar.gz file with instruction file >>> to unpack as needed. >>> >> That I find almost[1] entirely pointless. If all it does is drop a >> tarball somewhere, it's actually easier to ignore your package and >> simply download the tarball from mediawiki.org which has the added >> benefit of getting me the very latest version! >> >> If there's going to be a package, the package should really deliver >> some added value so there is a benefit to doing 'pkg install mediawiki' >> instead of 'wget mediawiki.org/latest.tar.gz' (not the real URL..) >> One good way to deliver that added value is with a ready-to-go >> configuration tuned to OpenSolaris, such as in the drupal example above. >> >> >> [1] Still has the benefit of bringing in dependencies. >> > >
