Ginnie,

I've forwarded a few parts of this thread to the writer for the Application Packaging Developer's Guide. Once you've reviewed this information, I'd like to see what we could do to get the information into the relevant docs.

Another option is this information could be written up as a technical article and posted on the Solaris Technical Articles and Tips page on developers.sun.com (http://developers.sun.com/prodtech/solaris/reference/techart/index.html).

Thanks,

David L.

Virginia Wray wrote:

Hi David -

I'm a tech writer at Sun. I'm going to review this information and get back to you about adding this procedure to the docs.sun.com documentation.

Thanks,
Ginnie


David J. Orman wrote:

That feedback was excellent, that was extremely helpful. I'm sure it would help a lot of other people as well, maybe there would be a documentation resource we could start? I like wikis and all, but I'd be much more in favor of having something like sun's documentation. Or maybe we could get Sun to add it to the official docs. :P

Cheers,
David


In this case, 'the clean way' would be:

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...
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org


_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org



_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Reply via email to