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: 79c0639a5b5d940b224e56c3da92f2b6f2abe4b3
Page Name:inst
Date: 2014-12-16 16:38:52
Original User: mario
Next 83062c1b061ae247d88e5339d4896b1999db4363
Content

### inst cross-distro GUI installer (planning stage)

`fpm` already has the sh 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.

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.)

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

Selecting the right archictecture packages is the trivial part; and including `_all` always just as trivial.

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.

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.)