[Raion]

Ok, so now that I'm in the end stages of IRIX Community Edition's first release, this is a rough outline of the patchset specifications and designs. For convenience, this will be broken up into a few sections, and it's designed to teach the end user on how I went about developing and packaging these disparate programs, and how one can do the same.

IRIX and its installation structure

Whether you already have a background in software packaging, or none at all, it's relatively simple to understand this if you've unpacked a tardist before. At its basic level, IRIX is installed via different segments called subsystems. These correspond to and are organized to allow incremental upgrades easily.

In every tardist, you usually have:

eoe - Execution Only Environment. Binaries, scripts, code etc.
lib - Libraries
hdr - Headers
man - Manpages
relnotes - release notes

Specfiles

A specfile describes the various products and subsystems that are offered. In order to help you understand, here is how I reverse engineered it so I could replace the Perl:

Code:

product patch_perl
    id "Upgrades Perl to 5.30.2"
    image eoe_sw
        id "Perl Patch Image"
        version 1
        order 9999
        subsys base patch
            id "Perl Patch Image"
            follows eoe.sw.gifts_perl 0 maxint
            exp patch_perl.eoe_sw.base
        endsubsys
    endimage
    image lib
        id "Perl Patch Libraries Image"
        version 1
        order 9999
        subsys base patch
            id "Perl Patch Image"
            follows eoe.sw.gifts_perl_lib 0 maxint
            exp patch_perl.lib.base
        endsubsys
    endimage
endproduct

The product name doesn't matter, I only called it patch_perl for simplicity sake.

The big ones are "subsys base patch" which indicates this is a patch over the base system. The next one is "follows eoe.sw.gifts_perl 0 maxint". From my notes, this tells the packager "this is a patch over the eoe.sw.gifts_perl subsystem - therefore any files installed by it are replacing those in that subsystem. It can replace ANY version."

This repeats for libs, and for other products. In order to find the subsystems this belonged to, I used the versions command.

versions -I long | grep perl

Among the output, you'll find:

l    0    0 eoe.sw.gifts_perl      usr/bin/perl

This indicates /usr/bin/perl belongs to eoe.sw.gifts_perl

And yeah, it's a slow process. It's not fun. But it's what we gotta do, so I do it for you guys. 


IDBfile

The IDB file indicates the files that are going to end up in the final dist. Thus, swpkg allows me to select every file to include. Again, a slow process, but a rewarding one. 

It stores their path, mode, permissions, name, size etc. 

To build your own IRIX Patches

IRIX Community Edition's files on the gitea, such as our spec, idbfiles, build order etc. are MIT licensed, and free to use. But note, the MIT license is a legal document, thus taking our work and removing it is illegal. Therefore, if you want to make a distribution under a different license, I ask that you either ask me for permission, or develop your own tools and methodology and start from scratch. Obviously, the info here is free and clear to use. That's the point. 

So, after you build and install your software, make note of all the files you need to keep track of (use make -n for this - gmake and IRIX make both will do a dry test to show you what goes where) and your products and such, put them into the spec and IDB files as I described, and then use swpkg to create a dist, test test test as I am doing, and then release it. 

Obviously, this is not limited to userland stuff. I am starting small, and because I am, this will form a basis for other projects. Until IRIX Community Edition is stable and well-tested and available for all IRIX 6.5.22 and 6.5.30 supported systems, I won't personally require it for anything I release, but I will probably expect it to be present eventually when we have it. 

Keeping track of your changes

Use VCS of some kind to keep track. Keep documents of everything. The irixce-patchsets repo uses a BUILD-ORDER for now, but eventually once I have more people and a better way to do this we will probably automate our builds. Detail your hacks, so you don't have to backtrack or rediscover things.

Any questions?