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

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


Artifact [0db190cd6a]

Artifact 0db190cd6a48f740d16377b8569b93b5014511a2:

Wiki page [inst] by mario 2014-12-20 12:30:08.
D 2014-12-20T12:30:08.996
L inst
N text/x-markdown
P f94046e1b20e16117d382cb8bc426e478f192807
U mario
W 3514
### <kbd>*-t* `inst`</kbd> cross-distro GUI installer

State: *planning*

`fpm` already has the <kbd>sh</kbd> target for raw cross-distro packages. Other [attempts](wiki/Research) had been made at GUI installers (notably Autopackage [defunct] or [EPM](https://www.msweet.org/projects.php?Z2) [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](http://en.wikipedia.org/wiki/Ipkg) a .deb compatible format.
       * Mac OS X has [fink](http://www.finkproject.org/) to handle .debs.
       * Windows even has [wpkg.exe](http://windowspackager.org/) 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](wiki/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.

Z 49bd5117546811cd169016cd1e854767