Ports and Packages

A normal Linux distribution tries to only expose the user to one package management system. Ubuntu provides apt, Redhat rpm, Fedora dnf. These help to modularize the distribution into something that is universally manageable by *any user. Under the covers, there are still several package managers that must be satisfied, jpm - perl - python - ruby - etc.

In the ThinStation world, we are generating static images of file systems, and may need to work with two distinct package formats. The first one is a port. It behaves a lot like a typical desktop package, plus it handles source compilation, a feature greatly needed when going embedded. There is a central database, so you can track files, query dependencies, add and remove the package from the active filesystem. You can update the package and test the changes on an active, persistent filesystem.

When creating or adding new ports, you should try and make them as complete as possible. Include all the help, the examples, the configuration and init files you can find. They will be a good reference later, when we need to go thin; and compiling can take a while, so the less times we do that, the better. You should *not attempt to break a port into pieces like samba, and samba-devel. That paradigm is an over-complication required decades ago when computers where slow and space was pricey. Most projects do not lend themselves to such formatting, it increases development time, takes longer to compile, drops valuable reference material, reduces access to newcomers...yada, yada, yada, bad plan. Here are some good links for the crux ports ports system. [https://crux.nu/Wiki/FaqPortsSystem](https://crux.nu/Wiki/FaqPortsSystem). You can search here. [https://crux.nu/portdb](https://crux.nu/portdb).

The next phase is actually called a package, but it does not behave like a typical package. Here the goal is different. We want to reduce a regular package down to it's bare functional essentials for a purpose. No help, no includes, no examples and drop anything not essential to the task for which the package was made. Convert as much of the init process into static files as possible. Drop any files or functions that will attempt to change the filesystem after we have rendered it. Even the package manager itself must not be present in the final product.

Perhaps one of the more challenging parts to understand is the relationship between these two formats, and how to use them to extend the ThinStation environment.