Table of Contents

osFree distribution (draft I)

Package management

WarpIN

WarpIN as a package management tool, with enhancements. WarpIN's purpose is maintaining the installed packages database, understanding the .WPI format, installing/deinstalling each package

Package sources frontend

Also, a tool like eCoMarket or Linux-like repository access client is needed. It can be like apt or yum in Linux, but with OS/2 specifics. This tool must be separate from WarpIN, i.e., it is specific to repositories/package sources, not packages format. So:

it must handle different package sources, like

files in the current directory

special directory layouts (on the current machine, or on remote http or ftp server), like diskette images with bundles (as used by IBM OS/2 distributions so, the installer will be capable to install old IBM OS/2 distributions as well)

maybe, support for handling the different packages formats, other than WPI, because Netlabs, for example, prefer RPM's, so, it would be good to have support for them too, as they seem to be logical for ports from UNIX (but they are not suited well for native OS/2 applications). So, the support for the following formats would be desirable:

plain ZIP's with metainfo and installation scripts included (like it was in UnixOS/2)

maybe, even, the possibility to create the decentralised network of package repositories is needed – this will allow to use any nearest mirror, or use another mirror if the main mirror is down. Even we could try to create the repositories network on Peer-to-Peer basis ;) (Use Bittorrent or any other protocol via a separate plugin,like the one for ftp/http)

WarpIN enhancements

The enhancements to WarpIN should include:

“Sticky” flag for packages which should not be upgraded

Support for simultaneously existing versions of different packages with libraries, which are needed for different applications (aka branches support)

Coexistence of several package trees, which are updated separately, and do not influence other trees – some analogies with source code repositories with branches

Support for separating and merging the branches, rollback of packages to an older (but stable) version

The installer

response-file-driven installer:

response file can be created manually

response file can be generated by UI (VIO or PM-based)

so, installer must be divided into four separate parts:

UI for choosing user options and generating the response file interactively, it can be:

textmode UI with pseudographics

graphical, PM-based

installation engine, based on invoking the package access frontend to retrieve the packages. It acts according the response file

it can be started by an experienced user, system administrator, or by the installation UI.

installation engine is independent from UI and can be started separately; and more: the user can start the UI on one machine, save the resulting RSP (response) file and apply it on another machine, by pointing the installation engine to the needed RSP