哪位了解如何制作solaris下的安装包？给个例子？

flybean6

如题，哪位了解如何制作solaris下的安装包？给个例子，让俺学学。谢谢先。

yddll

拜托，这里是aix的版面

synco221

pkgadd -d

jtw

放错地方

nimysun

Solaris package creation walkthroughs
The impatient will probably just want to dive into a direct "walk-through" of how to create packages for blastwave. We aim to please, with two alternative walkthrough guides:
A " you're so lucky, you get all the easy packages" walkthrough (Recommended!)
A " I like to control everything, even when it breaks horribly" walkthrough
However, when you get lost, or when curiosity finally gets the better of you, come back to this page, and read the rest of it, for details of what is going on under the covers.
Mechanics of Solaris/SysV pkg creation
SysV(Solaris) packages are controlled by a 'prototype' file, that defines which control files, datafiles, and directories will be contained in the package. A sample prototype file will look like
i pkginfo
i depend
i copyright
d none /opt/csw/bin
f none /opt/csw/bin/links
The "i" is a funny way of saying "this is a control file". Other entries are for "normal" files and directories.
Package control files
pkginfo definitions
At minimum, your pkginfo file should contain the following information:
PKG=CSWxxxx
NAME=shortname - Long name after dash
ARCH=("sparc", "i386", or "all")
CATEGORY=("application" or "system")
VERSION=x.y.z
VENDOR=url://where.you.got.source packaged for CSW by Your Name
HOTLINE=http://www.blastwave.org/bugtrack/
EMAIL=yourlogin@blastwave.org
DESC=[Optional extra info about software. Omit this line if you wish]

These fields are used by scripts to generate catalogs and things, so it is VERY IMPORTANT that you stick to the above format. Please note that "shortname" should be a single lowercase word. Also be sure that what you pick for PKG is going to last forever, because changing it is a very messy thing.
Note that you do not have to set ARCH in the pkginfo file itself: You can set it on the command line when you create the package, with "pkgmk -a". [or, the "createpkg" utility will do it automatically for you]. See the examples lower down for details.
Please note that whatever you put in the DESC field, will be exactly how the package is listed in the packages listing. If you do not wish to provide a customized value, it will fall back to whatever you have as the "long name" in the NAME field.
Final note: Please do not use any apostrophe in the fields. (It makes putting the info in a database trickier). Especially do not use "GNU's xyz". Typical usage; "GNU emacs", not "GNU's emacs".
depend definitions
If your package depends on certain shared libraries being installed, it should have a 'depend' file specified. "man depend" for format of the file. You will almost always need a depend file. Generally speaking, it will have entries like the following:
  P      CSWgtk  GTK - The GIMP Toolkit
  P      CSWglib GLIB - Library of useful routines for C programming
If any packages in the depend file do not begin with "CSW", or "SUNW", go and read the "Build standards" section of this document.
EVERY SINGLE DYNAMICALLY LINKED LIBRARY used by your package, must have an appropriate entry in your depend file.
Generally speaking, it is best to use Solaris standard libraries and utilities. Unless there is an overriding reason, use the Sun ones. For example, unless there is a real benefit to using ncurses over curses, use the system standard curses library.
Many GNU programs use GNU gettext, and refuse to use Solaris standard gettext. Therefore, you should probably install CSWggettext, and declare a dependancy on it, for many programs, due to linkage of /opt/csw/lib/libintl.so.2
copyright file
Every package should have a basic copyright file detailing the author's intents.
Boot scripts
Some packages need boot scripts (auto-start scripts in /etc/rc*.d/ ). Some may only sometimes need boot scripts. It it up to the packager to decide whether the software is important enough to merit always starting it at boot-time or not. You should carefully consider which one is correct for your package.
Two opposite examples, are apache and rsync. Apache's sole purpose in life is to be a webserver. It makes no sense to install it, if you do not want it running as a demon. rsync, on the other hand, is commonly run manually, and only in certain cases is it desirable to run it as a demon. Correspondingly, CSWapache directly installs scripts in /etc/*, whereas CSWrsync does not.
If you choose to not to always start a demon at boot time, you should probably provide a sample boot-time script, in either the /opt/csw/share/progname/, or the /opt/csw/share/doc/progname/ directory.
If you do want to always start a demon, you will most likely want to create boot-time scripts the same way, whether you decide to create a relocatable package, or an absolute path package (see lower down for details). Here is an example of how you would do that, taken from CSWapache.
The following assumes that you have a 'pkgs' directory tree in your home directory where you keep pkginfo files, and other files relating to each package.
f none /etc/init.d/cswapache=/export/home/phil/pkgs/apache/cswapache 0744 root sys
s none /etc/rc3.d/S50cswapache=../init.d/cswapache
s none /etc/rc0.d/K16cswapache=../init.d/cswapache
s none /etc/rc1.d/K16cswapache=../init.d/cswapache
s none /etc/rc2.d/K16cswapache=../init.d/cswapache
s none /etc/rcS.d/K16cswapache=../init.d/cswapache

Note that there are links for both 'S' and 'K' names, which means the script must handle both 'start' and 'stop' arguments.
Nice start scripts will check for the presence of a config file, and not start the demon if it is not present.
Install/Remove scripts
Packages that need scripts to run when pkgadd or pkgrm are called, are the most complex to put together. They are also a potential security risk. Some people feel uncomfortable about pkgadding third party stuff that requires an anonymous script running as root. So if possible, it is best to avoid install scripts, if you can still stick with the "deliver a fully functional package" motto.
When they are required, however, very strict guidelines need to be followed.
For example, scripts should be written to be paranoid about the state of config files. A package may be in a partially installed state ; your script may be running for the second time on the same machine.
Additionally, when packaging demons, be aware of the fact that the demon may STILL BE RUNNING. Do not do anything that could potentially break services.
preinstall/postinstall scripts
Custom preinstall/postinstall scripts (and any other pkg scripts!) should be aware of altered root locations. This usually comes into play when installing via jumpstart. This can be done by taking advantage of the pkgadd supplied variable $BASEDIR. This is not entirely the same as the BASEDIR setting for a relocatable package
Let's say you have a file that your script needs to adjust, called /opt/csw/etc/configfile. If someone has called pkgadd with a different root directory (as would be done by jumpstart), then the full path to the file may actually be something like /a/opt/csw/etc/configfile.
In the above example, if your package is non-relocatable (does not normally have a "BASEDIR" set), then BASEDIR will be set for you as the prepended bit
BASEDIR=/a

If your package is a relocatable package, and would normally have its own BASEDIR=/opt/csw, then in the above example, BASEDIR would be set for your preinstall/postinstall/... scripts as
BASEDIR=/a/opt/csw

So, if you have a regular (non-relocatable) package, reference the above file in your scripts, as "$BASEDIR/opt/csw/etc/configfile".
For relocatable packages, reference it as "$BASEDIR/etc/configfile".

How to create the package file
AFTER you have created pkginfo, depend, and copyright files, you have to generate the "normal" part of the prototype file. You can do this by running a normal "install" of the software, then using the 'pkgproto' utility in one of the following ways:
#### Absolute-path package

touch /tmp/timestamp
##[make install]

(echo "i pkginfo"; echo "i depend" ;
echo "i copyright";
find /opt/csw -newer /tmp/timestamp
) > |pkgproto > prototype

strip /opt/csw/bin/*
pkgmk -r / -a `uname -p`
filename=software-ver-SunOS`uname -r`-`uname -p`-CSW.pkg
pkgtrans -s /var/spool/pkg /tmp/$filename CSWyourpkg
rm -r /var/spool/pkg/CSWyourpkg
#### Relocatable-path package

touch /tmp/timestamp
##[make install]

(echo "i pkginfo"; echo "i depend" ;
echo "i copyright";
cd /opt/csw ;
find . -newer /tmp/timestamp
) > |pkgproto > prototype

strip /opt/csw/bin/*
pkgmk -b /opt/csw -a `uname -p` BASEDIR=/opt/csw
filename=software-ver-SunOS`uname -r`-`uname -p`-CSW.pkg
pkgtrans -s /var/spool/pkg /tmp/$filename CSWyourpkg
rm -r /var/spool/pkg/CSWyourpkg

nimysun

Use the Absolute-path way, if your executables have compiled in paths to /opt/csw/something. Otherwise, you may want to use the Relocatable-path version.
If your package does not have any dependancies, you should remove the "i depend" part.
Note: You should look through the prototype file, and verify that everything is owned by "root bin", not "root other", or some other uid local to your system. The STANDARD UID/GID combination is root:bin, unless there is a special need
(eg: things owned by 'nobody' for security reasons, etc)
You should now have a shiney new package file to submit. But you need to build TWO packages: one for Solaris 8 x86, and one for Solaris 8 sparc. The good news is, you can just copy over the pkginfo, prototype, etc. files to the other machine after you have installed the binaries, rather than having to hand-edit that stuff again.
How to create the package file without root access
If you are on a system where you do not have root access (like the shared sparc build machine on blastwave.org), and dont have a custom prototype file to build a package straight from the build tree, there are a few different ways you could still make a package:
1.A hand-built prototype file that translates build dir files to final destinations.
2.An install as a non-root user, but hand-tweak the prototype file to have correct ownerships of files
3.Use a tool to make your shell think it can do root type operations like chown and chmod, even though it cant realy.
Both #2 and #3 require that the software allow itself to be temporarily installed to an offset location. eg:
/tmp/destdir/opt/csw/bin instead of /opt/csw/bin
"direct from build tree" method
If you have a relatively simple program structure to install, it isnt so bad to make the prototype file by hand. This essentially replaces the normal "make install" process, by writing your own virtual install process to "install" to a package tree. A really simple example is the "links" program. A sample prototype file would look like the following:
i pkginfo
i depend
i copyright
d none /opt/csw ? ? ?
d none /opt/csw/bin 0755 root bin
f none /opt/csw/bin/links=links 0755 root bin
d none /opt/csw/share/man ? ? ?
d none /opt/csw/share/man/man1 0755 root bin
f none /opt/csw/share/man/man1/links.1=links.1 0644 root bin
To take advantage of this, once you have your pkginfo, depend, and copyright files all in the current directory, (and have 'strip'ped the executables) you just have to run
pkgmk -b /build/directory/path
pkgtrans -s /var/spool/pkg `pwd`/links-xxxx.pkg CSWlinks
rm -r /var/spool/pkg/CSWlinks
fakeroot method
This method can also potentially work even without fakeroot, (assuming the software allows non-root installs). It just means that you have to adjust the permissions in the prototype file by hand.
To have this work correctly, the software MUST HAVE an "install" target that respects a root directory offset. For some reason, a common name for a variable to do this is DESTDIR [A possible alternative is INSTALL_PREFIX] . The example assumes that DESTDIR is in effect.
Other assumptions:
You have the 'fakeroot' software package installed.
You have a pre-written pkginfo file sitting somewhere like ~/pkgs/pkginfo.xx
You actually WANT to make a relocatable pkg (with the BASEDIR stuff)
You start in the top-level build directory for the software you are packaging.
You have already run "./configure --prefix=/opt/csw" or whatever is appropriate.

$ mkdir -p /tmp/destdir/opt/csw                  #This may not be neccessary
$ fakeroot /bin/ksh                   #Or choose another shell if you prefer
# make DESTDIR=/tmp/destdir install   #
# cd /tmp/destdir/opt/csw
# (echo 'i pkginfo' ; echo 'i copyright'; pkgproto . )>prototype
####  You may have to add other stuff like a 'depend' file to the prototype
# exit
$ cd /tmp/destdir/opt/csw
$ cp {SOURCEDIR}/LICENSE copyright
$ cp ~/pkgs/pkginfo.xx pkginfo
$ strip *bin/*
$ pkgmk -b /tmp/destdir/opt/csw BASEDIR=/opt/csw
$ filename=yoursoftware-version-SunOS`uname -r`-`uname -p`-CSW.pkg
$ pkgtrans -s /var/spool/pkg /tmp/$filename CSWwhatever
$ rm -r /var/spool/pkg/CSWwhatever

How this works, is that the "fakeroot" pretends to let you do chown and chmod things like root would do, and stores the new fake ownership values until you exit the fakeroot shell. It will NOT let you do things like modify /etc/passwd or /etc/shadow.
BTW: If you do NOT want a relocatable package, you should use the following proceedure instead

$ mkdir /tmp/destdir                 #This may not be neccessary
$ fakeroot /bin/ksh                  #Or choose another shell if you prefer
# make DESTDIR=/tmp/destdir install  #or gmake
# cd /tmp/destdir
# (echo 'i pkginfo' ; echo 'i copyright'; pkgproto .) |  
     sed 's: none : none /:' >prototype
# exit
[cp copyright and pkginfo files into current directory, then]
$ strip opt/csw/*bin/*
$ pkgmk -r /tmp/destdir
$ filename=yoursoftware-version-SunOS`uname -r`-`uname -p`-CSW.pkg
$ pkgtrans -s /var/spool/pkg /tmp/$filename CSWwhatever
$ rm -r /var/spool/pkg/CSWwhatever


Resources
For full details on the finer points of pkg creation, you can try "man prototype", "man -s4 pkginfo", or go to Sun's Application Packaging Developer's Guide pages
It is suggested that you keep around your pkginfo and depend files, and any build notes you may have, so that when it comes time to upgrade the package, you have an easier time of it.
blastwave standards
Please note: this page is fairly generic for SYSV packaging. If you are interested in more of the CSW/blastwave.org specific stuff, you should really look at our full packaging walkthrough page
Template archive
A "shortcut", if you will, can be taken by using Phil's template tarfile. This will extract an assortment of files to a 'template' directory. You should make your own directory to hold pkginfo type files, then copy the template files, and adjust as needed. [Although this tarfile may be a smidge out of date now]
After the first time you make a package, recreating it on the opposite CPU architecture will be trivial. Also, creating an updated package when new software comes out, will be similarly easy, as long as you keep around the directory with these files.

Signing up
Still up to the task? Then please let us know!







Auto Installation of Solaris Packages
What I often have to do is install a whole bunch of packages onto a new machine, (or domain on an Enterprise system), and if I had to do it manually, even with the benefit of a script to unpack each package tgz file, it'd take a lot of time. (Not as much time as compiling and installing all the files on each machine, but when you have to install all the files on a lab of 20 new machines, half an hour each makes for a long tedious day This way you can rcp out the scripts and the files, fire off the install scripts in parallel and then go chat to the cute new girl/guy).

What one can do is have a simple shell script which installs all of the packages you want, plus a special file which tells pkgadd to not ask you any questions and to just install the packages as is.

Here is a shell script to install a group of packages automatically:

#!/bin/sh -x
umask 000
/usr/bin/tar -xvvf GNUzip.1.2.4.SPARC.Solaris.2.6.pkg.tar
/usr/sbin/pkgadd -d. -a noask GNUzip
rm -rf GNUzip
/usr/local/bin/gunzip -c GNUbison.1.25.SPARC.Solaris.2.6.pkg.tgz | /usr/bin/tar -xvvf -
/usr/sbin/pkgadd -d. -a noask GNUbison
rm -rf GNUbison
/usr/local/bin/gunzip -c GNUcvs.1.9.SPARC.Solaris.2.6.pkg.tgz | /usr/bin/tar -xvvf -
/usr/sbin/pkgadd -d. -a noask GNUcvs
rm -rf GNUcvs
/usr/local/bin/gunzip -c GNUflex.2.5.4a.SPARC.Solaris.2.6.pkg.tgz | /usr/bin/tar -xvvf -
/usr/sbin/pkgadd -d. -a noask GNUflex
rm -rf GNUflex
/usr/local/bin/gunzip -c GNUgcc.2.8.1.SPARC.Solaris.2.6.pkg.tgz | /usr/bin/tar -xvvf -
/usr/sbin/pkgadd -d. -a noask GNUgcc
rm -rf GNUgcc
/usr/local/bin/gunzip -c GNUgdb.4.16.SPARC.Solaris.2.6.pkg.tgz | /usr/bin/tar -xvvf -
/usr/sbin/pkgadd -d. -a noask GNUgdb
rm -rf GNUgdb

You can see the pkgadd line has a -a noask option. This tells pkgadd to refer to the noask file when it reaches a point in the package installation where it needs to ask a question. The noask file essentially tells pkgadd to skip any checks and just go ahead. Since I've made all the packages I am installing, I know how the system will look after the bulk installation, and that suits me just fine.

The noask file contains:

mail=
instance=overwrite
partial=nocheck
runlevel=nocheck
idepend=nocheck
rdepend=nocheck
space=nocheck
setuid=nocheck
conflict=nocheck
action=nocheck
basedir=default

Below is a perl script to build another script which will do the bulk install for you. It relies on some conventions in the package name that don't always apply. For instance it will use the first word in the large package file to attempt to pkgadd the packge. E.g. when GNUbison.1.28.SPARC.Solaris.2.6.pkg.tgz is added to the system the package name to add is GNUbison. This is true for 95% of the packages. However some packages have names that won't fit into the nine character limit on package names so they have been 'crunched' up, or it made sense to call the package something else. E.g GNUghostscript installs as GNUghoscr and fvwm installs as fvwm2.

How does this affect the script below? Not too much since it automatically checks to see if the guessed at package installed. If it didn't, then it doesn't delete the files afterwards. If you don't actually want to have your big package files deleted after installation then remember to modify the script first.

Note: You need to manually add GNUzip and perl onto your system first.

Here is is:

#!/usr/local/bin/perl
#
# Program : mkbulkinstaller
# Author  : Mark <mark@ibiblio.org>
# Purpose : Generate package bulk installation script
#
open(NOASK, ">noask");
print NOASK "mail=\n";
print NOASK "instance=overwrite\npartial=nocheck\nrunlevel=nocheck\n";
print NOASK "idepend=nocheck\nrdepend=nocheck\nspace=nocheck\n";
print NOASK "setuid=nocheck\nconflict=nocheck\naction=nocheck\n";
print NOASK "basedir=default\n";
close(NOASK);

opendir(DIR, ".");
@files = readdir(DIR);
closedir(DIR);

open(OUTPUT, ">bulkinstall");
print OUTPUT "#!/bin/sh -x\n";
print OUTPUT "umask 000\n";

# The pkgname is usually right 95% of the time. If the name is different then
# you will have to manually add the package.

foreach $file (@files) {
   next if ($file !~ /\.pkg\.tgz$/);
   print OUTPUT "/usr/local/bin/gunzip -c $file | /usr/bin/tar -xvvf -\n";
   $pkgname = $file;
   $pkgname =~ s/\..*//;
   print OUTPUT "/usr/sbin/pkgadd -d. -a noask $pkgname\n";
   print OUTPUT "if [ \$? -eq 0 ]; then\n";
   print OUTPUT "    /bin/rm -rf $file\n";
   print OUTPUT "fi\n";
   print OUTPUT "/bin/rm -rf $pkgname\n";
}
close(OUTPUT);
chmod(0755, "bulkinstall");
chmod(0644, "noask");



学到一定层次，建议使用C来make packages，我看高手都是这么作的。

文档号817-0406-11里面有详尽描述。