master

ben

features

fixes

gh-pages

Welcome

This is the
OS/2 Packaging Bootstrap Project

Its purpose is to enhance OS/2 Package Management.
Bootstrapping OS/2 Package Management is about adding the
OS/2 RPM packaging system to a fresh installation.
(or correcting an already bootstrapped system)

Why this project ?

Bootstrapping OS/2 is not as trivial as it may sound.
This is because OS/2 just has a lot of "legacy bagage" to be dealt with.
Unlike Linux distros for instance, which usually have just one packaging
system, OS/2 has many legacy installation methods. In fact, the WarpIN project
was started many years ago with the purpose of providing a new and unifying
way to handle packages and their proper installation and removal.

With the addition of the RPM packaging system for OS/2,
new powerful features have been introduced, but also the need to
"play well" with the existing OS/2 installation and removal methods.
With RPM coming from the *NIX realm, this involves
a little bit more than just porting it.

PKGBootstrap has its focus on addressing the above issues
(in a complementary manner)

Starting Points

Defining the Problem Domain

This is important because it determines what
problems need addressing here and what problems are out-of-scope.
A problem with booting OS/2 on an UEFI system with CSM would be outside the
domain while problems with getting the RPM packaging system on its feet
or dependency problems with upgrades would be inside it.
While the above may seem trivial, formally defining
it helps to keep development correctly focussed.

Identifying First Order Problems

This is important because to helps with establishing
priorities and separates easy-to-solve from difficult-to-solve
issues. This in turn helps on deciding which problems are on the
short-term track and which fall into the long-term category.

Identifying Possible Solutions

Almost always there are multiple ways of solving things.
Doing a little investigation into possible solutions can be helpful
for maintaining and expanding the chosen path in the future.

Having an abstract view of things eases development

Implementation

Think Object Oriented

Object Orientation is a good way to classify things.
Classification enables Modularity, Connectivity and Integration.
If we consider PKGBootstrap an Object, which contains a DependencyManager
Object and we also view ANPM as an Object, then an Interface can be established
which can be Implemented to make a Connection between
ANPM->resolveDependencies(...)
and
PKGBootstrap::DepencyManager->solveDependency(...)

Programming by Contract

An Interface Specification determines the Contract.
When Implementations are conform such a contract, they can replace
eachother. Such replacing enables quick-and-dirty implementations
to start with and replace them later with more fine-tuned ones.
(kinda like new WPS Classes can replace existing ones)

Separating Boilerplate Code from Custom Code

Boilerplate code can be easily generated.
By doing so, a developer can focus on the important stuff.
Examples of boilerplace code would be interfacing Rexx with C/C++.
After generation the developer can focus on the C/C++ parts.
This separation also helps with developer cooperation.

Using Interfaces and Implementations allows for flexibility

Using File Commander/2 as the front-end

As a self respecting OS/2 Developer,
you have of course a licensed version of
File Commander

No, not yet ?
Then consider getting one here and
it will become your Swiss Army Knife,
leaving you to wonder how you
ever managed without it.

The User Menus capability
of FC/2 is used to provide a menu-driven
interface to the build-system. This is done
by mapping menu-entries to build-actions.
Such actions can be targets in a
GNU Makefile, Ant BuildFile
or other means.

This project assumes FC/2 v2.40 is being used

Project Structure

After inventarisation of the problem domain has been done,
most probably some problem categories will be the result of this.
These will be the first-level directories, which can be
sub-divided down-the-tree in components.

Things are buildable when a fc.mnu file is present
(press F2 from within FC/2 to show it)

Contributor Branches

To allow for developer freedom and
cooperation, so called contributor branches
are present. Some 'first fiddling" will be at the ben
branch which can be checked out with:
git clone -b "ben" "http://github.com/os2dev/pkgbootstrap.git" "pkgbootstrap/ben"
which will result in a
pkgbootstrap/ben
work-directory for that branch.

Stuff from contributor branches will merge to master at later stages

Developer Notes

In no way this project has the intention to replace
or otherwise interfere with exsiting developments in this realm.
It is meant to be of a complementary nature.

What, you didn't know OS/2 is still g(r)o(w)ing strong ?

OS/2 Generation Next