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.

RPMs with web applications and version control

Any large web application requires version control. Whether it is subversion or CVS, ClearCase, or some other tool, a system must be in place to manage the software changes and updates, especially if more than one person is working on the code.

The organization of the code within the version control system should reflect the anticipated deployment approach. Many web applications have varying levels of functionality. One approach is to place th core code in a single directory. This includes the foundation architecture, default language and configuration, core functionality, and shared class definitions, as well as anything else that is required to support the system. Other modules can be in separate directories, which makes it easy to build RPMs.

Thus, the core RPM is created with the core files, and the other system components require the core for installation.

Since the RPMs use tar files to get the source, and tar files are a convenient way to update the code for development, scripts that generate the tar files, then the RPMs can support both development and distribution, by updating the internal/informal and external/formal deliverables. One script can extract the latest versions of the code from version control, create tar files, make them accessible to the RPMs and build the RPMs. The same script could also copy the new RPMs to a target server, which could then install them with little effort.

This approach may be too rigid for small applications or those that will be distributed to a larger community, as tar files are more flexible.

RPM BuildRoot

The BuildRoot setting in an RPM spec file is what allows you to indicate the target directory for the files you are including in the package.

md5 just-a-test ... just-a-list

Open source - open season

Open source is extremely accessible, meaning literally everyone can download it and use it.

This is a double-edged sword.

For people that want powerful sites with sophisticated applications, most of the materials are available, free. For people that want to learn how to use the software, they can use it.

However, it also means that virtually everyone can claim exposure and competence with the products.

The best qualified people will admit they have little experience, or that they are still learning. Those that are new to the field may be reluctant to admit their inexperience, for fear of missing out on an opportunity.

This is one area where requiring a certain level of related education can help differentiate between candidates that are likely to succeed and those who will struggle. The foundation knowledge provided by a computer science or software engineering degree, even if it isn’t web-specific, should help someone new to the field learn quickly and learn well.

Experience is not as reliable as a way to measure someone’s qualifications. If they have worked with something, poorly, for five years, they may not be a valuable asset.

Sample URLs can be used to assess a candidates skill level, but one must be sure their contribution is clearly stated. For example, one person might do the site design, another might do the server-side logic.

There are many self-taught web people who have excellent skills and experience, however, there are also many people who consider access and exposure to web code a license to practice - but lack the requisite skills to be part of successful projects.