en:docs:distribution

This is an old revision of the document!


osFree distribution (draft I)

  • osFree must use WarpIN as a package manager, with some enhancements
  • support for repositories? A repository client, something like apt or yum, but with OS/2 specifics.
    1. This tool must be separate from WarpIN, i.e., it is specific to repositories, not packages format. It's purpose is:
      1. understanding the repository format, different protocols support, like ftp, http, etc.
      2. maybe, support for handling the different packages formats, other than WPI, i.e., plain ZIP's with metainfo and installation scripts included(like it was in UnixOS/2), or RPM - for software ported from UNIX. The repository client will handle different package types via special plugins, and invoke different tools when installing packages (invoke WIC, ZIP, or RPM)
    2. WarpIN is for tracking dependencies, maintaining the local packages database, understanding the .WPI format
  • response-file-driven installation:
    1. response-file can be created manually
    2. response-file can be generated by UI (VIO or PM-based)
  • so, installer must be divided into four separate parts:
    1. UI for choosing user options and generating the response file interactively, it can be:
      • textmode UI with pseudographics
      • graphical, PM-based
    2. installation engine, based on invoking the repository client 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.
      • also, DOS (DPMI)-based version of the installation engine and UI would be desired
      • a Linux- or Win32-based version (?)
    3. repository client, handling different repositories:
      • including standard IBM OS/2-style “repository” with bundles and diskette images (so, the installer willbe capable to install old IBM OS/2 distributions as well)
      • different repository types and access protocols are implemented as special plugins
    4. enhanced WarpIN as the main package handling tool. The enhancements 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
      • Maybe, “Unstable” flag for apps and libraries, so, unstable package don't replace stable ones, they only create a separate branch in dependencies tree.
      • Coexistence of several package trees, which are updated separately, and do not influence other trees – some analogies with source code repositories with branches

Discussion

Enter your comment. Wiki syntax is allowed:
27 +8 =