On Wed, 20 Jul 2005, UNIX admin wrote:
> ...
> <snip>
>
> In this case, 'the clean way' would be:...
Wow, very nice write-up!
This looks to me like another example of something that should be
wiki'fied so it can evolve into an official, group-editable guideline
doc. For example, I would (predictably ;-) ) contributed this alternate
branch at step e)
--
e) Time to package. Check out the make methodologies of the
existing proven Solaris ports projects such as Blastwave, JDS,
OpenPKG, Pkgsrc, and SPS. If you like any of them, use their
procedure for building your makefile and patches and contribute the
result back.
--
Eric
>
> a) create a dedicated directory in /export, for example /export/scratch ("why
> should I use /export, and not some other arbitrary mount point / directory?"
> would be a good way to 'step back' and think about things. Perhaps a hint can
> be gleaned from the documentation. "What is /export designed for?")
>
> b) read and understand the "Application Packaging Developer's Guide". Make
> some "test packages" with one or two files to learn how it works.
>
> c) get the software to compile.
>
> d) try to optimize the compilation:
> "Improving Code Layout Can Improve Application Performance" by Darryl
> Grove at
> http://developers.sun.com/prodtech/cc/articles/codelayout.html
> is simply great stuff packed with tons of useful information.
>
> e) time to package. Write a generic package template which can be easily
> edited. Building could be automated and simplified with `make`, which is an
> ingenious tool. Any time invested in learning to use `make` is returned
> tenfold or even hundredfold. Otherwise, just copy the "pkginfo" and other
> package templates and edit them manually. This is probably the simplest thing
> to do at the beginning while you're still learning.
>
> Sooner or later you'll hit the `make install` part, which pollutes the
> consistency of a system. How do you work around that? It turns out Solaris
> already provides the facilities to do it. As it turns out, we can trick `make
> install` with some clever and 'creative' use of lofs(7FS), the loopback
> virtual FileSystem. (`man lofs` might do good at this point.)
>
> So, let's create our sandbox in which to install:
>
> mkdir -p /export/scratch/opt/php-5.0/ /export/scratch/etc/opt/php-5.0/
> /export/scratch/var/opt/php-5.0/
>
> The above [I]directory structure[/I] assumes one has compiled the software
> with the right prefixes, for example
>
> ./configure --prefix=/opt/php-5.0/ --confdir=/etc/opt/php-5.0/
> --datadir=/export/php-5.0/ --logdir=/var/opt/php-5.0/ && make
>
> Notice how we're trying to adhere to SVR4/POSIX/Sun mandate in laying out our
> directory structure?
>
> To be really clean, we should have done something along the lines of:
>
> /opt/SUNWphp/5.0/
> /etc/opt/SUNWphp/5.0/
> /var/opt/SUNWphp/5.0/
> /var/opt/run/SUNWphp/5.0/
> /export/SUNWphp/5.0/
>
> or we could have also done:
>
> /opt/SUNW/sbin/
> /opt/SUNW/bin/
> /opt/SUNW/share/man/
> /opt/SUNW/...
> /var/opt/SUNW/...
> /etc/opt/SUNW/...
>
> Where "SUNW" would have been replaced by the "stock symbol of the company".
> For example, "Blastwave" uses "csw" (although it should really be "CSW").
>
> Now that we have our directory structure, it's time for some magic:
>
> mount -F lofs /export/scratch/opt /opt
> mount -F lofs /export/scratch/var /var
> mount -F lofs /export/scratch/etc /etc
> make install
> umount /export/scratch/opt
> umount /export/scratch/var
> umount /export/scratch/etc
>
> Now look into /export/scratch/. `make` "magically" installed all the files
> there. From this point on, it's a walk in the park to package the software,
> and start testing the package...
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
