(Category) (Category) SCO comp.unix.sco.programmer FAQ. :
Packaging for SCO OS's
This is a guide to packaging your programs to install on SCO OS's
gerberb@zenez.com
Subcategories:
(Category) What is the SCO Product Engineering Toolkit (PET)?
(Category) Packaging with CDMT
(Category) Package Management with Software Development Tools (UnixWare 7/OpenServer 6)
(Category) Metapkg

Answers in this category:

(Answer) What is the recommended Packaging Tool?
(Answer) How to use Metapkg
(Answer) Porting Guide (OpenServer 6)
(Answer) Upgrading from OpenServer 5.0.X to OpenServer 6.0.

[New Answer in "Packaging for SCO OS's"]
(Category) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) Packaging for SCO OS's :
What is the SCO Product Engineering Toolkit (PET)?
PET is a retired tool kit for Unix 3.2v4.x, Open Server/Open Desktop 1.0, 2.0 and 3.0 and XENIX.
 
The SCO Product Engineering Toolkit (PET) Release 4.0 is shipped with the Open Desktop Development System and is incorporated as a set of packages with the SCO UNIX System V/386 Release 3.2 Development System Version 2.0.
The PET automates the process of creating custom installable applications and device drivers. The PET consists of utilities, configuration files, example init, prep and removal scripts, along with on-line manual pages.
The tools that will be most frequently used are the shell scripts docut, mkcuts and mkflops. Other tools are: diskimage, fdfit, mkmaster, mkperm, pkgsize, volno and hocheck, most of which are called by one of the first two utilities. A brief description of each follows:
Utility Description ------------------------------------------------------ docut Creates an application distribution and generates a mkmaster script for manual control. mkcuts Creates custom installable distributions and can create disk images and a sum list. mkflops Creates output floppy disks using disk images created by mkcuts or diskimage. mkperm Creates a product permission list and is executed when docut is run. fdfit Fits file archives onto media volumes and is called by mkcuts. diskimage Creates disk images for rapid copying of the distribution files and is called by mkcuts. pkgsize Updates size information for package in special permlist comment and is called by mkcuts. volno Updates volume number information for files and is called by mkcuts. hocheck Compares permlist with current and past distributions.
The PET consists of the following configuration files:
/etc/default/petkit /usr/lib/petkit/site_variables /etc/fdformats
The PET also contains example init, prep, and example XENIX and UNIX device driver scripts. These files are: /usr/lib/petkit/samples/init.sample /usr/lib/petkit/samples/prep.sample
/usr/lib/petkit/samples/xenix.idd/init.idd /usr/lib/petkit/samples/xenix.idd/install.xxd /usr/lib/petkit/samples/xenix.idd/xxd.rmv
/usr/lib/petkit/samples/unix.idd/init.idd /usr/lib/petkit/samples/unix.idd/prep.xxd /usr/lib/petkit/samples/unix.idd/xxd.rmv /usr/lib/petkit/samples/unix.idd/install.xxd
The PET is also capable of creating compressed distributions.
For additional information on the PET refer to the SCO Product Engineering Toolkit Guide.

gerberb@zenez.com
Subcategories:

Answers in this category:
(Answer) Packaging for Unix 3.2v4.x, Open Server/Open Desktop 1.0, 2.0, and 3.0

[New Answer in "What is the SCO Product Engineering Toolkit (PET)? "]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) Packaging for SCO OS's : (Category) What is the SCO Product Engineering Toolkit (PET)? :
Packaging for Unix 3.2v4.x, Open Server/Open Desktop 1.0, 2.0, and 3.0
This is now a retired tool set.
gerberb@zenez.com
[Append to This Answer]
(Category) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) Packaging for SCO OS's :
Packaging with CDMT
This is taken from the online SCO documentation.
  http://osr600doc.sco.com/en/manCDMT/CONTENTS.html

Custom Distribution Mastering Toolkit (CDMT)

Intro

    introduction to Custom Distribution Mastering Toolkit utilities 
ccs
    component control script 
ccsSetup
    standard shell functions library 
ccsUpgradeTool
    merge contents of old configuration file with newer version 
cdmtArchive
    generate custom-installable archives from the $CDMT_DIR/sso hierarchy 
cdmtCompress
    populate $CDMT_DIR/sso with compressed component distribution files 
cdmt.config
    specify default CDMT configuration 
cdmtConvert
    convert list of relative pathnames to CDMT input files 
cdmtInput
    CDMT input files 
cdmtParse
    create the SSO databases from the CDMT input files 
cqs
    component query script 
customSched
    schedule event for custom outside of the standard phase model 
dosfloppy
    place a custom-installable distribution image on an existing DOS floppy filesystem 
ssoPatch
    map new version or component into an SSO member file 
ssoPathMap
    allow shell program to interpret a patch area

gerberb@zenez.com
Subcategories:

Answers in this category:
(Answer) CDMT is the old tool for packaging on OpenServer 5.0.X
(Answer) SCO Software Manager (custom)

[New Answer in "Packaging with CDMT"]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) Packaging for SCO OS's : (Category) Packaging with CDMT :
CDMT is the old tool for packaging on OpenServer 5.0.X
CDMT was the old tool for packaging on OpenServer 5.0.7.
  http://osr600doc.sco.com/en/manCDMT/CONTENTS.html

gerberb@zenez.com
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) Packaging for SCO OS's : (Category) Packaging with CDMT :
SCO Software Manager (custom)
This is taken from the SCO online documentation.
  http://osr600doc.sco.com/en/man/html.ADM/custom.ADM.html

custom(ADM) custom -- install, remove, or list software products and components
Command syntax /etc/custom [ -h machine ]
/etc/custom [ -h machine ] -G all | index | last | summary
/etc/custom [ -h machine ] -p product -b | -d | -e | -l | -r |-t | -w [ package ... ]
/etc/custom [ -h machine ] -p product -A | -i | -L | -u [ package ... ] [ -N machine ] [ -gnQ ] [ -m device | -F image_file ... | -z image_directory ]
/etc/custom [ -h machine ] [ -p product ] -D | -E | -R [ package ]
/etc/custom [ -h machine ] [ -p product ] -D | -E | -R package
/etc/custom [ -h machine ] [ -p product ] [ -v type [ package ... ] ] [ -x ]
/etc/custom [ -h machine ] -V [ -x ]
The syntax above covers all the new features of custom, and should be used for all new custom products. However, custom also recognizes the following syntax, so that old-format custom command lines (for example, in existing programs or scripts) continue to work:
/etc/custom -a package ... [ -m device ] /etc/custom -s prd -i [ package ... ] [ -m device ] /etc/custom -s prd -l | -r [ package ... ] Desktop syntax Double-click on the Software Manager icon.
(The default location of the Software Manager icon is in the System Administration window.) Description With the custom utility, you can selectively install or remove portions of the UNIX system or other products, list the files of a product, and verify file permissions, ownership, size, and other details. You can manage the software on both local and remote machines.
You can use the standard custom command line to install single-volume products (such as drivers) from DOS-format floppies.
The custom utility presents SCO OpenServer products in the following hierarchy:

    * The product itself, composed of one or more parcels, packages, or components.
* The components, each one a unit of software that cannot be split into smaller units for distribution. A component is organized into a hierarchical tree of packages.
* The packages, each one a unit of software that can be installed or removed. A package can contain other packages, and each package is ultimately composed of files.
Each product and component has its own version number. A package inherits the version number of its parent component.
An example of a product is the SCO OpenServer(TM) Enterprise System, which consists of many components. One of these components is the TCP/IP runtime system, which in turn consists of packages such as the PPP runtime utilities, the TCP administration package, and several others.
SCO products may also contain parcels, which are groups of related packages pulled together from several different components. For example, the manual pages for all the components of the SCO OpenServer system might be gathered into a parcel called Online Man Pages.
Only root can run custom. custom runs either interactively or non-interactively. Command options This section describes the command line for the new custom format. For information on the old-format command line (retained for backwards compatibility), see the ``Old-format command options'' section in this manual page. Do not use the old command-line options in new programs or scripts.
Each command line in the new custom format must specify exactly one action using one of these options: -A, -b, -d, -D, -e, -E -G, -i, -l, -L, -r, -R, -t, -u, -v, -V, or -w.
You can specify packages (or whole components) with the -A, -d, -D, -e, -E, -i, -l, -L, -r, -R, -u, and -v options. Use spaces to separate package names (for example, SCO:Unix:BASE SCO:Unix:CSH). If you list package names, custom acts on just those packages. If you list component names, custom acts on all the packages in each component.
When you use -p product followed by an option without any packages, the specified action affects the entire product. When you list packages, the specified action affects the listed packages only.
Note that if you use -D, -E, or -R without -p product, a package or component must be specified.
custom accepts the following options:

-A [ package ... ]

    apply a software patch to a product. The patch can come from distribution media or from a server. package must be the name of the patch, and -p product must name the product with which the patch is distributed, not the product to which the patch is applied. 
-b [ package ... ]
    export the listed packages. 
-d [ package ... ]
    disable part or all of a product. (Disabled software cannot be run locally, but is still available for networked installation.) Follow this option with a list of packages to disable part of a product. If you do not specify a package list, custom disables the entire product. 
-D [ package ]
    disable an applied software patch. (Disable rolls back a patch from the client-side configuration files, but not from the shared-side binary files.) 
-e [ package ... ]
    enable part or all of a loaded product. (Enabling completes the final phases of installation, so that the software can be used.) Follow this option with a list of packages to enable part of a product. If you do not specify a package list, custom enables the entire product. 
-E [ package ]
    enable an applied software patch. (Enable re-applies a patch to the client-side configuration files, after the patch has been disabled.) 
-G all
    display the details of all tasks in the custom logfile. custom logs a procedure each time you invoke one of these options: -A, -b, -d, -D, -e, -E, -i, -l, -L, -r, -R, -t, -u, -v, -V,-w. 
-G index
    display the details of a specific task in the custom logfile, where index is the index of the task, as shown in the summary. 
-G last
    display the details of the last (most recent) task in the custom logfile. 
-G summary
    list a summary of all tasks (such as installations and removals) in the custom logfile. 
-i [ package ... ]
    install or re-install part or all of a product. Follow this option with a list of packages to install part of a product. If you do not specify a package list, custom installs the entire product. 
-l [ package ... ]
    list some or all of the files in a product. Follow this option with a list of packages to list part of a product. If you do not specify a package list, custom lists the entire product. 
-L [ package ... ]
    install part or all of a product through the load phase only, making it available for enabling or fully installing on another machine across the network. (Loaded software is not configured for use.) Follow this option with a list of packages to load part of a product. If you do not specify a package list, custom loads the entire product.
If package is the name of a software patch, then -p product must name the product with which the patch is distributed, not the product to which the patch is applied.
-p product
    specify the product or parcel on which custom acts. The product name consists of a vendor part and a product code part separated by a colon (for example, SCO:odtps). You can also specify multiple products for installation. 
-r [ package ... ]
    remove part or all of a product. Follow this option with a list of packages to remove part of a product. If you do not specify a package list, custom removes the entire product.
If package is the name of a loaded software patch, custom unloads that patch. In this case, -p product must name the product with which the patch is distributed, not the product to which the patch is applied.
-R [ package ]
    roll back an applied software patch. (Rollback reverses the -A apply option, but does not unload a patch that is actually loaded on the system.) package must name the software component that contains the patch.
You can only roll back the most-recently applied patch. Run custom -R several times in succession to roll back more than one patch.
-t [ package ... ]
    unexport the listed packages. 
-u [ package ... ]
    upgrade part or all of a currently installed product. Use this option without an argument to upgrade only the currently installed packages. Follow the option with a list of packages to install additional packages of the same product. 
-v type [ package ... ]
    verify system software, where type is quick, thorough, config, symlinks, or strict. Depending on the type specified, -v and -V check for broken or missing symbolic links, and incorrect file permissions, owner, group, and number of hard links. (To fix these discrepancies automatically, include the -x.) The verification can also check for missing files and for incorrect file type, checksum, and size. (These discrepancies cannot be fixed with the -x option -- these must be fixed manually after exiting custom.) You can use your backups or the customextract(ADM) utility to restore missing files.

    quick
        check for broken or missing symbolic links, incorrect file permissions, owner, group, and number of hard links. Does not report on size or checksum changes for configuration (non-shared) files, because these often change as part of normal operation. It does not verify checksums for shared files, nor does it remove a ``corrupt'' setting in the custom database. 
thorough verify the checksums for shared files in the selected packages, in addition to the checks made during the quick option. This option removes a ``corrupt'' setting from the custom database.
config report checksum changes for configuration (non-shared) files, showing which configuration files have changed since installation. Also verifies permissions, owner, group, number of hard links, symbolic link target, export location, file type, and size for each configuration file in the selected packages.
symlinks report symbolic links that should link a file from /opt or /var/opt to an external directory, but are broken or missing. A weekly cron job runs this option on the entire system and mails the report to root.
strict report all discrepancies, including expected discrepancies such as changed configuration files and missing optional files. This option can take a long time.

-V

    same as -v, except it verifies the entire product. 
-x
    fix file permissions, ownership, and other details.
Use -x with the -v and -V options.
-w [ package ... ]
    change product or component database(s) to match how the files currently appear on the system. This is a very dangerous procedure.
Follow this option with a list of packages to change just the part of the database covering specific packages. If you do not specify a package list, custom changes the entire product or component database.
These options specify an installation source other than the default media device:

-F image_file ...

    specify a list of image files to use in place of removable media. Use full pathnames for the image files.
You can use -F with the -i, -L, and -u options.
-m device
    specify an installation media device other than the default device, /dev/rinstall. (/dev/rinstall is also called the 0 device, as in /dev/fd0.) The device argument must be a valid block or character device name.
You can use -m with the -i, -L, and -u options.
-z image_directory
    specify a directory of image files to use in place of removable media. Use the directory's full pathname.
You can use -z with the -i, -L, and -u options.
These options let you manage software on another machine or install software from another machine:

-h machine

    execute custom on the specified machine (or ``host''), for networked software management. 
-N machine
    specify a machine on the network serving as the source of the software to be installed. The software can be installed or loaded on the named machine or can reside on removable media or in image files on the named machine.
You must supply a password when prompted.
These options are used by the Installation Query Manager (IQM):

-g

    display the (post-IQM) progress messages of the initial system load in graphical mode. 
-n
    prevent custom from prompting the user to insert media. 
-Q
    specify that custom is being executed from the IQM. 
Desktop options Entering:
custom [ -h machine ]
without any other options or arguments runs a completely interactive custom session. The -h option executes the session on the specified machine.
The custom Software Manager window appears with a list of the software products currently installed on your local host. Each line gives the product name and release number, a symbol indicating the installation state of the product, and a symbol indicating whether you can view the packages of the product.
From this window, you can:
    * Access a remote system (from the Host menu)
* Exit custom (from the Host menu)
* Run the installation task (from the Software menu)
The installation procedure takes you through several windows, which prompt you to name the type of media (or the source machine) you are installing from, choose a full or partial installation, and (if choosing a partial installation) select the packages to install.
* Remove products or packages (from the Software menu)
After you select the packages for removal from the Software Manager window, additional windows prompt you to confirm the removal and remind you of any dependencies.
* Verify (and optionally fix) file permissions, ownership, and other details (from the Software menu)
The verify procedure prepares a report of any discrepancies found between the files on the system and the corresponding product or component database. The procedure then offers any or all of the following choices: print the report, save the report to a file, and correct discrepancies.
* Examine the files, dependencies, applied patches, PRD value, version number, size, and installation state of products or packages (from the Software menu)
* Load software (from the Software menu, under Advanced Options)
The load procedure resembles the installation procedure, but the software is only copied from the media, and is not configured for use.
* Update a product or component database (from the Software menu, under Advanced Options)
This is a very dangerous procedure.
* Apply, roll back, load, unload, or view patches on installed software (from the Software menu)
* View the components and packages in a product (by double-clicking on a list item, or from the View menu)
Old-format command options The information in this section should only be used to administer programs or scripts that were written under an old version of custom.
Each old custom command line must specify a set and an action (unless it uses the -a action option, which does not require a set).
The set determines which component custom acts on. The set option is:

-s prd

    specify the prd value (short product code) of the product you want custom to act on. 
Include only one action option on each command line. For action options that accept a package list, list the package names as they appear on the package definition lines (marked by #@) in the component perms list (for example, BASE CSH). Separate the package names with spaces.
The action options are:

-a package ...

    install part or all of a new product. -a does not require an accompanying set specifier, but you must specify a package list following the option. To install the entire new product, specify the ALL package. 
-i [ package ... ]
    install or re-install part or all of a set. Follow this option with a list of packages to install part of a set. If you do not specify a package list, custom installs the entire set. 
-l [ package ... ]
    list some or all of the files in a set. Follow this option with a list of packages to list part of a set. If you do not specify a package list, custom lists the entire set. 
-r [ package ... ]
    remove part or all of a set. Follow this option with a list of packages to remove part of a set. If you do not specify a package list, custom removes the entire set. 
You can also specify an alternative media device:

-m device

    specify an installation media device other than the default device, /dev/rinstall. (/dev/rinstall is also called the 0 device, as in /dev/fd0.) The device argument must be a valid block or character device name.
You can use -m with the -i and -a options.
Examples To install the CORE and XDEV packages of the UNIX Development System component (unixds) of the Open Desktop Development System product (ods), enter:
custom -p SCO:ods -i SCO:unixds:CORE SCO:unixds:XDEV
To upgrade the previously installed packages of the ods product, using the /dev/rinstall1 drive, enter:
custom -p SCO:ods -u -m /dev/rinstall1
To install the entire ods product from the remote machine mcgee, enter:
custom -N mcgee -p SCO:ods -i
To install the entire ods product from the image directory /u/user1/ods/archives/TAPE, enter:
custom -p SCO:ods -i -z /u/user1/ods/archives/TAPE
To install the entire ods product from a list of image files, enter:
custom -p SCO:ods -i -F /u/user1/product1/file1 /u/user1/product1/file2
To remove the CORE and XDEV packages of the unixds component of the ods product, enter:
custom -p SCO:ods -r SCO:unixds:CORE SCO:unixds:XDEV
Examples in the old format To install the CORE and XDEV packages of the Development System component (unixds) of the Open Desktop Development System product (odtds), enter:
custom -s unixds -i CORE XDEV
To install the TCPSRC package of whatever new product is in the /dev/rinstall1 drive, enter:
custom -a TCPSRC -m /dev/rinstall1
Warning The product database and component databases define what files exist in a product, where they reside, what their permissions are, and everything else that determines the product's behavior. Therefore, if you change a product or component database with the -w option (or the Update database graphical option), you change the product itself. You no longer have the same product you installed, and the only way to return to the original product is to reinstall. Limitations custom does not let you manipulate individual files. If, for example, a file becomes damaged or destroyed, you must use customextract(ADM) to install individual files. When using custom on the console to install a new package, if you select CD-ROM for the media without a CD in the CD-ROM driver, an error message prints on top of the screen, garbling the custom display. You should be able to correct this problem by forcing the screen to redraw with <Ctrl>R. Files

/var/opt/K/SCO/SoftMgr/*/custom/custom.log

    custom log file 
History The main changes to custom (new command line options, new syntax, and a new graphical interface) are detailed in the ``Description'' and ``Options'' sections of this manual page. Read those sections carefully.
Some of the specific changes to watch for include:
    * custom now accepts single-volume products (such as drivers) on DOS-format floppies.
* custom no longer uses ``Services'' or ``Service Components.''
* The command line for old-format custom no longer includes these options: -d (specifying the Development System set), -o (specifying the Operating System set), -b (enforcing dependencies specified in bundled products), or -v (specifying verbose output).
See also customquery(ADM), df(C), du(C), fixperm(ADM), hierarchy(M), customextract(ADM), installpkg(ADM), perms(F), xinstall(ADM)
``Installing and managing software components'' in Installing and removing software Standards conformance custom is conformant with Intel386 Binary Compatibility Specification, Edition 2 (iBCSe2); it is an extension to AT&T System V developed by The Santa Cruz Operation, Inc.
gerberb@zenez.com
[Append to This Answer]
(Category) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) Packaging for SCO OS's :
Package Management with Software Development Tools (UnixWare 7/OpenServer 6)
Software development tools

Below is the location on the SCO site for Software Development Tools.

  http://uw714doc.sco.com/en/SDK_tools/CONTENTS.html

This is for UnixWare 7.1.x and OpenServer 6
gerberb@zenez.com

Subcategories:

Answers in this category:
(Answer) Orignal Tools for UnixWare 7.1.4

[New Answer in "Package Management with Software Development Tools (UnixWare 7/OpenServer 6)"]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) Packaging for SCO OS's : (Category) Package Management with Software Development Tools (UnixWare 7/OpenServer 6) :
Orignal Tools for UnixWare 7.1.4
The .pkg format was the original tool set for UnixWare 7.1.X.
gerberb@zenez.com
[Append to This Answer]
(Category) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) Packaging for SCO OS's :
Metapkg
Metapkg is the new tool for creating packages for OpenServer 5.0.X, OpenServer 6, and UnixWare 7.1.4.
gerberb@zenez.com
Subcategories:

Answers in this category:
(Answer) What is Metapkg.
(Answer) Using Metapkg to create custom and pkgadd installable packages.

[New Answer in "Metapkg"]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) Packaging for SCO OS's : (Category) Metapkg :
What is Metapkg.
Metapkg creates the installable packages for OpenServer 5.0.7, OpenServer 6, and UnixWare 7. It is the prefered tool.
gerberb@zenez.com
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) Packaging for SCO OS's : (Category) Metapkg :
Using Metapkg to create custom and pkgadd installable packages.
From the presentation at the SCO TEC Forum 2008
  This was presented by Ron Record and John Wolfe of SCO.
Their entire presentation is at
http://www.sco.com/2008forum/presentations/Record_Wolfe_Packaging_Tools_OSR6_UW714.pdf

Below is the instructions from the presentation. Special Thanks go to both Ron Record and John Wolfe.

Download and install the latest metapkg media images

  ftp://ftp2.sco.com/pub/skunkware/osr6/vols/

Metapkg documentation is installed in

  /usr/share/doc/packages/metapkg/
Metapkg examples are installed in
  /usr/share/doc/packages/metapkg/examples/
Metapkg convenience scripts are installed in
  /usr/share/doc/packages/metapkg/scripts/
The metapkg and reman binaries as well as mkcdmt and mkpkgadd symbolic links are installed in /usr/bin/

 Create input directory and populate dist directory
Create dist/cntl/ scripts, if any
Create <package name>.mkcdmt control file
Specify non-default permissions and ownership
Symbolic links specified as additional exports
Dependencies and updated versions listed here
Run mkcdmt. For example:
mkcdmt -f -h -d `pwd` -P gimp \ -D "GNU Image Manipulation Program" \ -V 2.2.7Sb -p `pwd`/gimp.mkcdmt
Run make

Sample Metapkg Control File.

 prepare ("Checking and preparing distribution") {
 auto_compress_texinfo();
 auto_format_mansource();
 auto_strip(TRUE,TRUE);
 }
 package ("/", "${METAPKG_DESCRIPTION}", "QT3") {
 file ("/usr/lib/qt3/mkspecs/unixware-cc/qmake.conf") {
 access (SERVER);
 }
 file ("/usr/lib/qt3/lib/libqt-mt.so.3.3.8") {
 addexport ("/usr/lib/qt3/lib/libqt-mt.so", normal);
 }
 }
 component ("qt3", "${METAPKG_VERSION}", "${METAPKG_DESCRIPTION}") {
 dependency ("SCO:gwxlibs");
 upgrades("^3.3.5*");
 }

Shortcut Scripts

 See /usr/share/doc/packages/metapkg/scripts/
 Create a gzip'd tar archive of the distribution files relative to / and name 
 it <package name>-<version>-dist.tar.gz
Place the gzip'd tar archive in the /dist/ directory that the setup shell script points to
Create an empty directory <package name> in the packaging directory and cd into it
Run ../setup
Run the listlinks script to create entries for symbolic links in the file /tmp/<package name>-symlinks
Edit <package name>.mkcdmt adding the above file to the “package” section. Run “MakeCDMT” then “make”


CDMT/Metapkg Documentation

 CDMT documentation
http://osr600doc.sco.com/en/manCDMT/CONTENTS.html
SCO Software Manager (custom) documentation
http://osr600doc.sco.com/en/man/html.ADM/custom.ADM.html
Installing and Managing Software Components
http://osr600doc.sco.com/en/INS_install/swaN.admin.html
Installing/Managing Software Over a Network
http://osr600doc.sco.com/en/INS_install/swnetN.netinstall.html
Metapkg documentation
ftp://ftp2.sco.com/pub/skunkware/osr5/devtools/metapkg/doc
Porting Guide:
http://www.sco.com/support/docs/openserver/600/porting/osr6portingTOC.html
Upgrade Guide:
http://www.sco.com/support/docs/openserver/600/upgrade/index.html
Online Documentation and Late News
http://www.sco.com/support/docs/openserver
OpenServer 6 Support Download Page:
http://www.sco.com/support/update/download/product.php?pfid=12&prid=20
SCO “Legend” Mailing List: Public
Legend-subscribe@list.sco.com
legend@sco.com
Porting/Migration Alias:
osr5to6@sco.com
Knowledge base: http://wdb1.sco.com/kb/search


[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) Packaging for SCO OS's :
What is the recommended Packaging Tool?
Metapkg is the recommended tool set.
  ftp://ftp2.sco.com/pub/skunkware/osr5/devtools/metapkg/doc/

 Name    Size    Last Modified
 File:README.txt         1 KB    07/27/2007      12:00:00 AM
 File:cdmt.txt           3 KB    07/27/2007      12:00:00 AM
 File:changes.txt        7 KB    07/27/2007      12:00:00 AM
 File:control.txt       45 KB    07/27/2007      12:00:00 AM
 File:pkgadd.txt         4 KB    07/27/2007      12:00:00 AM
 File:usage.txt          7 KB    07/27/2007      12:00:00 AM
 File:xml.txt            1 KB    07/27/2007      12:00:00 AM

gerberb@zenez.com
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) Packaging for SCO OS's :
How to use Metapkg
MetaPKG Command Line Usage


MetaPKG has several command line options that are required, and many more that control the way in which packages are generated. This document describes the main driver program's command line options. Each backend driver can add options of its own.

Preparation

Before invoking MetaPKG, you must ensure that your distribution tree is laid out in a very specific manner. Many of these paths are hard-coded into MetaPKG, so be careful with file and directory names.

MetaPKG starts its work in a BASE DIRECTORY. Lets call this $BASE. This directory is expected to contain at least a directory called dist/. Lets call this directory $DIST. This is the directory that contains the software you want to distribute in a package. For historical reasons, and showing its CDMT lineage, $BASE is also expected to contain a directory called input/, which we will call $INPUT. This is the directory in which all of the packaging files will be generated. It is the input into the packaging system.

The files in $DIST are typically the results of doing `make install'. MetaPKG knows how to deal with two types of distribution tree: flat and productized. A flat $DIST is one that contains only a single package, and will likely contain direcories called `/usr/bin' or `/usr/lib' etc. This type of structure is used when you are packaging one single program as an installable product. A productized $DIST is one that contains multiple programs, each of which will be a package in its own right, grouped into one or more components. In this case each subdirectory under $DIST contains a discrete package which has its own `/usr/bin' or `/usr/lib' etc. MetaPKG uses the name of each subdirectory to contruct a default package name, which can be changed in a MetaPKG control script. Unless otherwise instructed, MetaPKG will create a single component which contains all of the packages. You can invoke MetaPKG in `component mode', in which case each subdirectory under $DIST will create a new component containing a single package. Using the control script, you can fine tune this to any degree you like, creating components that group packages together in any way you chose.

Please note that the arguments here can also all be set via a control script file. All except for the -p argument, which names the control file, and the -d argument, which sets $BASE.

Required Arguments

-d directory

  Sets $BASE to the specified directory. Remember $BASE must contain the
-P string
  Sets the product name to the specified STRING. The string must be valid
  for the chosen backend driver (see below).
-C string
  Sets the component code to STRING. The STRING must be valid for the
  chosen backend driver. If you are not running MetaPKG in component mode,
  this is simply the default component name to which any dangling packages
  (packages that were not explicitly added to a component in the control
  script) will be assigned.
-D string
  Sets the description of the product to STRING.
-V string
  Sets the version of the product to STRING. This must be a valid version
  for the backend driver.
-B name
  Sets the backend driver to the driver specified by NAME.  Use the -?
  argument to list all of the compiled in backends. This option may be
  omitted if the `metapkg' binary is linked to a name that automatically
  selects a backend driver. For example, if invoked as `mkcdmt', the
  `cdmt' driver will automatically be selected, or if invoked as `mkpkg',
  the `pkgadd' driver will automatically be selected. See the documentation
  on each driver for the list of names that each one recognises.
Optional Arguments ------------------
-p file
  Use the specified FILE as a control script file.
-f
  Indicates that $DIST is a flat hierarchy. That is, it contains only a
  single package.
-c
  Sets `multiple component' mode. Indicates that $DIST has more than one
  package, and rather than making a single component that includes all
  of the packages, make a component for each directory found, which contains
  a single package that is the contents of the directory.
-i
  Instructs MetaPKG to use the permissions exactly as they are found in
  $DIST. Usually, MetaPKG guesses the correct ownership and permissions.
  This flags indicates that that work has already been done in preparing
  the $DIST directory.
-m
  Usually, manual page source files are omitted. This tells MetaPKG to
  include manual page source files in the installable product.
-v
  Usually, MetaPKG guesses the correct disposition for files. This option
  tells MetaPKG to treat all files as `variable' files, or files that can
  have their contents changed.
-s
  The reciprocal of -v. Instructs MetaPKG to make all files `static'.
-r
  For backends that support it, instruct MetaPKG to make all files
  available early (in the CDMT backend for example, means to always
  export files in the REGISTER phase).
-M name[=value]
  Defines macro NAME. If no VALUE is specified, set it to the value `1'.
  Otherwise, set it to the specified VALUE. Such macros are only useful
  to the control script.
-I list
  Control auto-preparation functions. This option has a different meaning
  depending on whether or not a control file is being used. If a control
  file *is* being used, the LIST is a list of auto-preparation functions
  to ignore, even if they are specified in the control file. If there is
  no control file being used, LIST indicates the list of auto-preparation
  functions to execute before processing each package. The list can be
  one or more of the following, each separated by a comma:
    automan   - do (or do not) automatically format man pages
    autotexi  - do (or do not) automatically compress TeXinfo files
    autostrip - do (or do not) strip and mcs -d all binaries
    reman     - do not obey explicit reman directives in the control file
    texifo    - do not obey explicit texinfo directives in the control file
    exec      - do not obey exec or script directives in the control file
    all       - all of the above.
-W
  Indicates that any warning messages are OK, and that MetaPKG should go
  ahead and produce output files regardless of the warnins.
-X level file
  Sets debugging to the specified LEVEL, and to be redirected to the given
  FILE. The higher the LEVEL, the more verbose the debugging output.
-N
  Normally MetaPKG will automatically add inter-package and inter-component
  dependencies as they are defined in the control file. This option will
  stop that from happening, and you should ensure that all dependencies are
  correctly set in the control file.
-?
  Displays the program usage information, lists the defined backends and
  the program and backend version numbers.

gerberb@zenez.com
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) Packaging for SCO OS's :
Porting Guide (OpenServer 6)
SCO online Porting Guide
  http://www.sco.com/support/docs/openserver/600/porting/osr6portingTOC.html

gerberb@zenez.com
[Append to This Answer]
(Answer) (Category) SCO comp.unix.sco.programmer FAQ. : (Category) Packaging for SCO OS's :
Upgrading from OpenServer 5.0.X to OpenServer 6.0.
This is the online docs from SCO.

  http://www.sco.com/support/docs/openserver/600/upgrade/index.html

gerberb@zenez.com
[Append to This Answer]
Previous: (Category) Hardware related programming
Next: (Category) Known bugs in SCO Programming Environments.
This document is: http://www.zenez.com/cgi-bin/scoprogfaq/faq?file=128
[Search] [Appearance] [Show Top Category Only]
This is a Faq-O-Matic 2.721.