| Home | :: | About | :: | Download | :: | Install | :: | Use | :: | Manual | :: | Changes |
There's a small but important package repository - the release repository.
This repository ships 3 packages:
Of these, TRIBzap supplies most of the zap package management
and systems administration tools.
The TRIBrelease-name package just supplies the /etc/release
and /etc/os-release files, which contain the main identifiers
of exactly which version of Tribblix is installed.
The TRIBzap-upgrade package supplies the list of upgrade candidates and the upgrade script. The reason for shipping the upgrade script in this package is so that it can be updated to match new upgrade candidates.
Within the lifetime of a given release, only the upgrade package will ever get updated. And it gets updated whenever the next release becomes available. Initially, therefore, the upgrade list is essentially empty (technically, it contains itself).
There are some assumptions in the build process based on my personal
environment, namely that lots of stuff is present under the directory
/packages/localsrc/Tribblix which I have as an environment
variable THOME. You'll need THOME set for much
of the following to work.
There are 2 source code repositories of interest that you'll need to check out:
cd $THOME git clone https://github.com/tribblix/tribblix-release
and
cd $THOME git clone https://github.com/tribblix/zap
plus you'll also need the tribblix-build repo if you haven't
checked it out already,
cd $THOME git clone https://github.com/tribblix/tribblix-build
There are several parts to this. First we need to add the information for
a new release to the tribblix-release repo. For example, to add
m36 as a successor to m35, for both normal Tribblix
and OmniTribblix:
cd ${THOME}/tribblix-release
./mk_pkgs.sh -p i386 -r m36 -c m35
./mk_pkgs.sh -p i386 -r m36 -v lx -c m35
What this will do is add a directory for each release with the appropriate metadata files in it.
Next create the driver maps for ddu. This requires you to have built the gate already, as it needs a source for the driver mapping. This makes assumptions about naming and locations.
./mk-driver-map.sh -V m36 ./mk-driver-map.sh -V m36lx
Then you can create the packages. There are actually 4 upgrade pathways here: m35 to m36, m35lx to m36lx, and then the cross-upgrades m35 to m36lx and m35lx to m36.
./mk_pkgs.sh -p i386 -r m36 -u m35 ./mk_pkgs.sh -p i386 -r m36 -v lx -u m35 ./mk_pkgs.sh -p i386 -r m36 -u m35lx ./mk_pkgs.sh -p i386 -r m36 -v lx -u m35lx
This will drop the packages into /tmp/pct, and also populate
per-release directories in ../release-repos.
For publication on the online repo, a catalog files is needed.
./gen_catalog.sh ../release-repos/m36.i386 > ../release-repos/m36.i386/catalog ./gen_catalog.sh ../release-repos/m36lx.i386 > ../release-repos/m36lx.i386/catalog
What the above will also have done is create the upgrade packages
for the m35 and m35lx releases, again in the
per-release directory in ../release-repos. Those will need
new catalogs as well:
./gen_catalog.sh ../release-repos/m35.i386 >! ../release-repos/m35.i386/catalog ./gen_catalog.sh ../release-repos/m35lx.i386 >! ../release-repos/m35lx.i386/catalog
Index | Previous Section | Next Section