Cross package maker. DEB/RPM generation or conversion. Derived from jordansissel/fpm.

βŒˆβŒ‹ βŽ‡ branch:  cross package maker


Update of "inst"

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview

Artifact ID: 0db190cd6a48f740d16377b8569b93b5014511a2
Page Name:inst
Date: 2014-12-20 12:30:08
Original User: mario
Mimetype:text/x-markdown
Parent: f94046e1b20e16117d382cb8bc426e478f192807
Content

-t inst cross-distro GUI installer

State: planning

fpm already has the sh target for raw cross-distro packages. Other attempts had been made at GUI installers (notably Autopackage [defunct] or EPM [semi-active]). It's evident that a shell/scripting-based installer would be most portable/universal though.

Rationale

Thus the inst package is planned to be Shell+Python based initially.

  • The envelope format probably ought to be ZIP.
    • Allows the main Python payload to handle extraction easily - just an __init__.py necessary.
    • The pre-stub can just be a few lines then.
    • Alternatively and later a __init__.pl could be added, and a __init__.sh handler fallback in any case.
  • As GUI any installable toolkit may be selected (TKinter, Gtk, Qt), at least from the main Python payload.
    • The shell fallback may use xdialog/zenity or just xmessage.
    • The "GUI" may be as lean as just presenting package infos, a package selector, and presenting the installation just per xterm/rxvt/etc.
  • The ZIP thus is just a container, may bundle multiple concrete packages; for different architectures even.
  • Embedded bundles ought to be DEB packages.
    • Debian packages are by all accounts the most widely used system format; should thus be the preferred/primary actual packaging method.
      • (The LSB doctrine of baseline RPMs being the standard kind of flies in the face of reality.)
      • the Debian/Ubuntu family of distros are the most widely used ones.
    • DEBs are supported by alternative tools, and different platforms already:
      • OpenWRT uses opkg/ipkg a .deb compatible format.
      • Mac OS X has fink to handle .debs.
      • Windows even has wpkg.exe with semi-compatible .deb support.
    • And as fallback for other distros there are extremely obvious options:
      • Using alien for implicit converison and installation.
      • Download or bundle a minimal fpm to convert deb to rpm.
    • Else just can be extracted raw using an unzip | ar | tar pipe. (Invoking post-install scripts is more work then, of course.)

Format idea

A inst bundle would simply be a collection of:

pkgname-1.0.inst (pyzip)
 β†’ __init__.sh
 β†’ __init__.py
 β†’ pkgname_1.0_x86.deb
 β†’ pkgname_1.0_amd64.deb
 β†’ libraryxy_3.7.0_all.deb

So an outer ZIP layer, and DEB packages and distinct installer scripts/fallbacks within.

Notes

Selecting the right archictecture packages is the trivial part; and extracting _all always just as obvious.

The concrete installation process will regularily just chain the whole process to gdebi or dpkg -i or alien -i, otherwise use a two-liner for ar→tar extraction, and lastly XDG/PK register all files.

Most work is likely just exception-probing for and implementing GUIs on Tkinter / Gtk / Qt in the Python payload.

As for the fpm plugin, it can just collect ready-made debs, zip them with payloads. (Or trivially preinvoke the -t deb handler itself for plain file input.)

Research

See Research on prior cross-distro installers. In particular SuperDebs/RUNZ looked sensible (just wasn't cross-distro). Listaller might be worth investigating further for implementation details/reuse.