-
Notifications
You must be signed in to change notification settings - Fork 0
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.
We do not remain on the tip of any other disto. For better or worse, we are forked. The only versions of any packages, are the ones in the ThinStation git repo. You can update the version number and (fingers crossed)rebuild the port on your own, or bribe me to do it.
When updating 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 to research ports.
The package management utilities.
https://crux.nu/Wiki/FaqPkgUtils
You can search the crux port database here.
The Archlinux ports system is also an excellent reference, but they have different goals and values.
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 port 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.
A good starting place is to run mkrepackge <port>, and most of the common tasks will be scripted for you and a package will be created at /build/packages/<port>. It will create among other things, a file called install at /build/packages/<port>/build/install. This can be customized to further reduce unnecessary files for your desired task.