On Wed, Jun 27, 2007 at 05:15:43PM +0530, Arvind Srinivasan wrote:
> Hi,
>
> I would like to propose a few changes to the way the webstack sources
> are organized and built in the svn repository.
>
> Currently, the top level of the source tree contains the following:
> webstack/trunk/src % ls
> .svn/ APC-3.0.14/ README
> freetds-0.64/ freetype-2.2.1/ gd-2.0.33/
> gdbm-1.8.3/ gettext-0.16/ gmp-4.2.1/
> mod_fcgid.2.1/ mod_perl-2.0.2/ mysql-5.0.33.32bit/
> mysql-5.0.33.64bit/ ncurses-5.5/ openldap-2.3.30/
> perl-5.8.8/ php-5.2.0/ rails/
> ruby-1.8.5/ rubygems-0.9.0/ squid/
> suhosin-0.9.16/ tidy/
>
> Each of these top-level directories contain the entire source tree of
> the component. In some cases, these sources have been modified. These
> top-level directories also contain a make_solaris.sh script.
> webstack/trunk/src % ls imap-2006c1
> ./ README ipopd/ mlock/
> ../ SPECIALS mailutil/ mtest/
> .svn/ SUPPORT make_solaris.sh* src/
> CONTENTS an* makefile.nt tmail/
> LICENSE.txt c-client/ makefile.ntk tools/
> Makefile dmail/ makefile.os2
> NOTICE docs/ makefile.w2k
> OSTYPE imapd/ makefile.wce
>
>
> a) I propose that we remove the version numbers from the directory names
> and instead just use the component names - APC, ruby, php etc - for the
> top-level directories.
+1
I believe that your suggestion is to have version appeared in the tar suffix
e.g perl-5.8.8.tar.Z
>
> b) Under each top-level directory, I propose that we do not check in the
> exploded version of the sources for each component. Instead each of
> these top-level directories will contain the upstream community's
> distribution of the sources (e.g. imap-2006c1.tar.Z), a Makefile and any
> source patches (maybe even a 'patches' directory containing all patches)
> that need to be applied to the upstream sources before we build the
> sources. Each component's Makefile will contain rules that will unzip
> the source distribution, apply any applicable patches, run any
> configuration scripts, build and install the component
>
> % ls imap (after my proposed changes)
> ./ Makefile src.patch
> ../ imap-2006c1.tar.Z
>
> Currently, the upstream community's distribution is not checked in
> anywhere and since the individual sources are checked in, it is quite
> easy to inadvertently change the sources and check that in (instead of
> applying the change as a patch). I think it will make maintenance much
> easier if we carry the upstream distribution as is and have the logic
> for unzipping/configuring/building the component in Makefiles.
+1
Few comments :
(a) I believe that build will happen is a separate generated subdirectory e.g
build or SunOS5.10.xx
(b) I believe that order of patches will be appeared in Makefile or may be
a sub makefile patch.mk.
(c) Saving patches in separate directory also looks ok. How will we track
patches
diffs when we upgrade the component? For an example suppose current php
version
is 5.2.0 and we have 4 patches e.g fix1.patch fix2.patch fix3.patch and
fix4.patch.
Now we upgrade to 5.2.3 and now we need say only two patches fix1.patch and
fix2.patch.
(d) Is ".Z" a preferred way to ".gz" or ".bz2"?
(e) source rpm in redhat linux also have some similarity as far as patches is
concerned.
>
> c) I propose that we replace the top-level build_webstack.sh script with
> a Makefile
+1
>
> This is similar to what is being done for sfw components e.g.
> http://cvs.opensolaris.org/source/xref/sfw/usr/src/cmd/apache2/Makefile.sfw
>
> Comments?
>
> Arvind
Regards,
Basant.
