Category: "Drupal"

info2spec.sh - Translator from Drupal .info to RPM .spec files

This is a very simple translation of a Drupal .info file into an RPM .spec file. It may be useful in identifying methods to assemble complex Drupal installations on dedicated servers or VPSs where the modules can be managed as RPMs. This would not be useful for casual users. It also assumes the modules will not be modified, and requires careful composition of the .info files by contributors.

I had difficulty posting the script in the blog, so the link provided must be used.

To run it, pass the URL of the module to download, for example: ./info2spec.sh http://ftp.drupal.org/files/projects/annotationfield-5.x-1.x-dev.tar.gz

It was tested with the annotationfield module.

Be sure to set up an .rpmmacro file at the account level.

* CAUTION *

  • Hasn’t been (and isn’t going to be) tested with an actual RPM build
  • Does not (and probably won’t) handle intermodule dependencies or conflicts

Drupal RPM spec file generator module

A Drupal RPM generator module could scan the modules installed and extract the following information:

  • Source file (full URL)
  • Requires - the modules required to support each module
  • Provides - the name of the service/capability/feature provided by each module
  • Conflicts with - modules which cannot be installed with each module

The standard BUILD, SPECS, SOURCE, RPM, SRPM directories can be used for the build process. The Drupal RPM generator would write .spec files to the SPECS directory for each module. .rpmmacros would indicate the target directory, and other common constants.

This allows a development environment to be quickly converted from a .tgz installation to an RPM managed production server.

Drupal RPM Component Construction

The next major step for Drupal will be assembly of an RPM repository that bundles compatible components into RPMs that can be managed as such. In order for this to succeed the server filesystem architecture must be created such that a single installation of Drupal can run multiple sites.

Open Source RPM .spec file

This is an RPM .spec file for dojo, that will install it in /opt/os/dojo

.rpmmacros

%_topdir /home/account
%_buildroot %{_topdir}/BUILD
%_tmppath %{_topdir}/tmp

dojo.spec


%define targetdir opt/os/dojo
%define version 1.1
%define release 1
%define name dojo
%define dojo %{name}-release-%{version}.%{release}

Summary: dojo Toolkit
Name: %{name}
Version: %{version}
Release: %{release}
Copyright: GPL
Group: Development/Tools
#Source: dojo-release-1.1.1.tar.gz
Source: http://download.dojotoolkit.org/release-1.1.1/dojo-release-1.1.1.tar.gz
Provides: %{name}
BuildRoot: %{_buildroot}
%description
dojo Toolkit

%prep
%setup -q -n%{dojo}
tar tzf %{_topdir}/SOURCES/%{dojo}.tar.gz | grep -v "/$" | sed "s/dojo-release-1
.1.1//"| awk '{ print "\"/%{targetdir}"$0"\""; }' > %{_topdir}/outfile
mkdir -p $RPM_BUILD_ROOT/%{targetdir}
rm -rf $RPM_BUILD_ROOT/%{targetdir}/*
%build -n%{dojo}
%install -n%{dojo}
mv * $RPM_BUILD_ROOT/%{targetdir}
%clean -n%{dojo}
rm -rf $RPM_BUILD_ROOT

%files -f %{_topdir}/outfile

The same general approach will work for Zend, Smarty, Drupal and many others. Expect to have to adapt the name of the tar/gzip/zip file - hence the use of the %{dojo} macro. The tar tzf command allows the RPM to be installed in a directory with other code. Although it is unlikely dojo would be placed in a directory with other code, the tar listing allows you to place several tars in the same directory, and still manage them with RPMS.

Download: http://wirehopper.com/dojo-1.1-1.i386.rpm
Source RPM: http://wirehopper.com/dojo-1.1-1.src.rpm

If you use the RPM to install dojo, use a symlink (ln -s /opt/os/dojo dojo) from DocumentRoot. This will allow a single installation of dojo to support all your sites.

Drupal RPM architecture

Drupal is one of the most popular content management systems and modular web application architectures available.

It would be an excellent system to deploy an RPM management system on. This system would generate .spec files for the modules, ensuring dependencies could be enforced and allowing the use of yum or other methods to automate upgrades.

The success of this approach for developers would be dependent upon their ability to architect their implementations without modifying Drupal and interfacing correctly to the module system.

It also requires that Drupal serve as a server component, rather than just an account-level application. Managed carefully, with configuration files and other innovative methods, rapid deployment of manageable Drupal sites would be extremely cost-effective.

http://web-notes.wirehopper.com/2008/06/23/open-source-rpm-spec-file

1 2