The first thing you should have is the 04x “Pack” script which is included in the pack-packager-##-lightning.tgz file available on most FREESCOsoft package mirrors in the 04x non-package directory.

These scripts and binaries can run on any lib5 Linux system such as Slackware 3.x, Redhat 4.x, SuSe 5.x, or FREESCO 0.3.x and 0.4.x

Once you have unpacked the pack-packager into the packaging directory you should run the command using the same name, version, and author name of the 03x package you are converting:

Pack Name-Version-AuthorName

This will create an entirely new package structure along with the new 04x package scripts with the proper names and files. The first time this is done it is recommended that you include the extra help text that will be asked during the package creation.

Next unpack the 03x package.tgz archive and copy it to the new 04x package structure. But be careful NOT to overwrite ANY of the current/new 04x scripting such as the /pkg/rc/rc_name script or the new /addons/*.cgi scripts.

You will notice that the /pkg/lib directory is no longer in the 04x package structure. This directory is now replaced with the /pkg/lib-pack directory. This new directory is identical to the 03x /pkg/lib directory with one exception.
You should never rename libc.so.5 or make any special scripts to deal with that library independently of the system. In some 03x packages the library was renamed to libc.so.5.no or it was moved to a completely new location. This is
no longer necessary or desired in 04x packages.

You will also see that in 04x packages there are multiple places for scripts and language files separately. The main /pkg/rc/rc_name script should NEVER have any printed words in it. Instead use variables for the printed text or questions.
Then you will find there is a matching script containing the variables that correspond to the language in the /pkg/lang/name-ver/english/ directory. There are multiple languages with the base set of instructions already defined such as start/stop/restart and that is usually enough for simple packages. But where man pages or configuration files are concerned it may require extra coding to copy the correct language files into the correct place. All language files need to be placed inside the “pkg/lang/name-ver/'language'” directory structure.
This includes configuration files with readable help text and any extra scripting that includes text. In most cases the conversion is just going to be in English for most packagers and English is a required default language. But
if you have the capability to translate it into another language that is the desired option as well. You may also get help from others to translate the files or get them translated at a later date and repackage it again. But if the
package is not created in a manor to support multiple languages that option will not really be possible later.

Once the above has been completed you need to look through the 03x install script and see what special things the install script has done and translate that script into the new 04x install script. You will again notice that there
are multiple versions of the install script. One main script that has all of the main functions in it and multiple secondary scripts with the various language conversions in it. You will also see that the main package information variable inside the install script is replaced with a name-version-author.info file. You should make a brief explanation of what your package is and what it does in a non-tech manor so that everyone can understand what the package does without a degree in computer science an abbreviation interpretation manual and a word dictionary. Simple and straight forward. For example; if the package is an SMTP server, say “This package is a mail server using the SMTP protocol”. However as the new description is now a file versus the old variable that was somewhat restrictive
it is a good idea to really make your package explanation much more detailed because this text is what will be displayed on FREESCOsoft and inside the package viewer. You should also try and get as many language conversions as you have language options within the package.

Once all of these scripts are completed you can use the Pack command again:

Pack name-version-author

You will be prompted to see if the languages in your package are really supported or not. In most cases the system will display more built in languages than what the install script will support. So you answer “n” and then manually
enter the languages that the install script supports using a space delimiter.

Finally once you are satisfied that the scripts are accurate you can run the final Pack command.

Pack -pack name-version-author

Which will create a finished 04x package as 'name-version-author.pkg'

Be aware that the .pkg extension is not a real extension other than what was chosen to represent a FREESCO 04x package. The real extension should you choose to manually tinker with 04x packages is .tgz
Also know that the 'mc' package for 04x has the compatibility to open these package files just by using 'Enter' while on the package name.
I strongly recommend looking inside some of the existing 04x packages to see how some things are done and if there is any questions on packaging don't hesitate to ask on the FREESCO forum and I will make every effort to help. Be aware that we are now striving for no defective or non-compliant packages for the 04x series.

Also know that the dependency section of packages now has the capability of installing a dependency during the package installation. There is also the capability to either ignore or terminate an install based on whether the
dependency is passed or not. So packages that require sub parts of other packages should never be included directly if another package already contains those components. They should just be listed as a dependency for that
specific package. The end result to this is that some 03x packages may end up being more than one 04x package. So if you package needs something like 'bzip' or any standard binary that would normally be a Linux distro then you would list the 'utils_' package as a dependency rather than adding those binaries into your package. Then in the 'preinstall' section of the install script list the dependency as required and fail the install unless the utils package is installed.

The theory behind this type of package creation is that a common binary should never be removed just because some specific package is removed. That binary might be needed by several packages and doing things in this manor prevents
package removal from damaging other components as it has in the past.