Eric Reid wrote: > > Deliver Drupal6.x into OpenSolaris We've been talking about how there's going to need to be some careful analysis of the approach on integrating pure webapps like this one. We're waiting for the first case to come through so the discussions can be had in a concrete context. Looks like Drupal is the first one so it gets to do the hard work to pave the way...
I see a number of editorial corrections to the ARC case, but I'll defer those for now so we can cover the main issues first. Peter had a lot of good questions, I'll try not to repeat too many of the same. > Drupal's basic architecture provide a basic 'core' of functionality > (including 'core' modules), optionally augmented by additional and > freely available modules for additional functionality and presentati > The intent here is to integrate only the Drupal 6.x 'core' into SFW. How and where are users expected to install the modules? By adding subdirs under 'modules'? Will that be supported? Where/how are they configured? > Drupal core itself consists of less than 4MB of PHP scripts and > configuration files, designed to be copied into and reside in the > Webserver's top-level document directory. As such, no new "/usr" > subdirectory needs necessarily be created for Drupal installation. Please classify the delivered files into a) those which are always read-only (i.e. the core "binaries" of the implementation) b) those which are may be edited by users to customize the system (if any) c) those which are always written into, such as configuration and log files This will help understand what's what and where should things go. BTW does Drupal need/recommend any configuration in apache config files? > MySQL 4.1 or 5.0: satisfied by SFW's /usr/mysql BTW you'll want to depend on /usr/mysql/5.0 not MySQL4 (which is going away). > /var/apache2/2.2/htdocs/index.php The package can't install right onto top level htdocs. This isn't the only web app content package (well, it is today, but presumably if it goes in, many others will follow). It'll need to peacefully coexist with other content. It might possibly install into a dedicated subdir of htdocs. Later in the spec there is this scary warning: > Note: currently, existing webserver DOCROOT content should be > moved before install, otherwise it may be lost or corrupted. which suggest maybe it can't get along peacefully with other docroot content? What's the issue there? > Drupal, as explained above, does not require a new directory entry > /usr, but rather 'piggybacks' on an existing Apache HTTP server > 'htdocs' directory. As such, the proposed directory layout for > Drupal 6 is: > > Where <WEBSERVER> is nominally (but not limited to) /var/apache2/2.2: Can you expand on "(but not limited to)" given the context of the package? The primary decision to make is the main install location. Viable options I see are: a) Somewhere under htdocs (but not at the top level) Main drawback here is that OpenSolaris is still also distributed as DVD images with all the packages. But not everyone wants drupal in their docroot (really, most people don't). If OpenSolaris had already transitioned to a IPS-only distribution model this would be a non-issue since nobody would install SUNWdrupal6 unless they really wanted it. But that world is still some ways away. b) Somewhere under /usr and you provide a script a user can run to hook it up into the final location (and the script can do additional groundwork beyond just bits). c) Nowhere - tell users to get it from drupal.org. This option needs to be considered. If options a|b don't make life easier for the user (or worse, make it harder by e.g. having very stale content) then this might be a viable option. I don't know if it is, but I'll want to see a section in the ARC case analyzing why it's not ;-) As Peter said, SUNWdrupal6 needs to provide some value-add over simply grabbing the bits from drupal.org. Preconfiguration, seamless integration, "works out of the box", etc.. are all potential good reasons. > 4.6. Installation/Configuration [...] > 4) Manually create Drupal database/schema Manually by running some provided script, or literally "manually" by telling the user to start typing in SQL? > We also do not feel that enforcement of RDBMS/webserver/PHP > dependencies are appropriate at package install time. The only Clearly it'll need to depend on apache22 and php5 packages. The db dependency is more complex, because either MySQL or Postgres can fulfill the role, so you don't want to hardcode one or the other (certainly not both ;-) so no good answer there. > 4.7. Internationalization > > While localized versions of Drupal 6 core files are available from > the Drupal Community, we do not feel it appropriate to include them, > and therefore open the "pandora's box" of which to include. How about all of them? If not, why not? (In general for an ARC case, you'll want to document the reasoning of any given decision.) > 4.8. Integration With OpenSolaris Infrastructure > > As Drupal 6 is a very lightweight mechanism, depending upon existing > executable mechanisms (Apache, PHP, MySQL/Postgres), there is no need > to consider integration with OpenSolaris mechanisms such as SMF. ... and it should be the correct reason or it'll get nitpicked ;-) The correct reason not to implement SMF is not because drupal is a "lightweight mechanism". It's because (I'm assuming) one doesn't start drupal, one starts apache, which is already hooked into smf. > 4.11. Packaging and Delivery > > We propose to package Drupal 6 into a single package, named > SUNWdrupal6. IFF the install location ends up being tied to Apache 2.2 then you'll want to name the package so it reflects that, as some of the other apache22-dependent modules have done. > This naming scheme will allow for future coexistence > of multiple versions of Drupal within SFW. The package name alone doesn't achieve that... if you need to support versioning of the app, the install location needs some versioning as well, or the future package will just stomp on this one. > 4.12.3. Exported Interfaces > > NAME STABILITY NOTES > > SUNWdrupal6 committed package > drupal6 umbrella Man Page committed man page If modules (see earlier) are supported, that's an interface. Are there config interfaces/files (other than the GUI itself)? -- Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems
