More thinking on software bundles for Linux

The post Rethinking the Linux distibution made me revisit some of the ideas which I had in the past trying to address which in my opinion are major limitations in the current main packaging systems:

• No support for multiple versions of the same software
• No support for rollbacks

A software bundle composed of the application and all it's "non core" dependencies can  also add some other benefits:

• Cross Linux distribution delivery
• Fine grain control of libraries and options used by an application
• Reduced complexity with the removal of dependencies management

The disadvantages are:

• Increase on Disk and RAM usage from software containing different versions of common libraries
• Applying security fixes  on dependencies requires re-creating/re-distributing every affected bundle

Possible approach for implementation:

Compiling

Adapt an existing source base build system like Arch's "makepkg", with the following changes:

• Run time prefix must be set to /opt/bbundle
• Build definitions for dependencies must be contained in the master build definition (this will lead to build definitions redundancy across bundles but will remove the risk of breaking builds by sharing dependencies building rules) 

Bundling

The bundle file format should be a commonly used archive format, since tar does not provide indexing, .zip is a better option. Having an indexed archive will allow to reduce download sizes by inspecting the bundle  contents prior to the download and skipping the download for common files found at installed bundles. In order to save on-disk space, the bundle installer should check for identical files across bundles and use hard links instead of duplicating files.

Installing

Bundles installation should be as simply as extracting the bundle archive into /usr/local/bbundle/bundle_name. A watching service must identify .desktop and other exportable resources and make them available from the host desktop environment.