While much of the Linux world is focusing on finding a way to package binaries in a distro-independent manner, I have a solution working itself out in my head.
Source code is already distro-independent, right? (the ./configure scripts always work out where everything is). But source is a pain to install sometimes, with you needing to read the mind of the developer in order to guess what dependency you're missing. And source is always unfriendly for newbies to install.
In addition, Debs, RPMs and Autopackages aren't exactly a cakewalk to create. Oh sure, you can create a Checkinstall Deb, but it's not a proper package with dependencies and stuff. Building a proper package is beyond the abilities of most volunteer helpdesk people (such as those as Ubuntu Forums).
So, why not create some sort of scripting framework for downloading, compiling and packaging source code? I have called my proposed framework "Bleeding Edge"
For instance, take the following code snippet:
from bleedingedge import *
require("libsdl1.2debian-all", Debian)
require("libsdl1.2", Mandriva)
require("sdl1.2", Suse)
require("libgl1-mesa", AllDistros)
sourceGet("http://www.sourceforget.net/myproject/myproject-beta.tgz")
configure()
make()
debian_install(maintainer="chris@hotmail.com")
rpm_install()
Let's take this line by line:
from bleedingedge import * - This imports all the modules from my source management system into the local namespace, for simplicity. In a real implementation, an ImportError would then call a function that downloads and installs the Bleeding Edge module.
The "require" functions take two arguments and one option: The first is the package name that is a runtime dependency of "myproject", and the second is the distribution that it is relevent to. The Bleeding Edge module has already checked to see what distribution we're compiling on, so it only runs the statements that are true for our distribution (including the "AllDistros" one later on).
The other option taken is for a specific version. Note that no actual build dependencies are listed: Bleeding Edge would know that the build dependency for "sdl1.2" is just "sdl1.2-devel" on Suse, for instance. Like any experienced Suse user would. If a particular make system is required (like Jam or Scons), that could be listed in the requires.
Sourceget() does what you'd expect - it downloads the source code as a compressed archive. However, it also untars and ungzips the source into a directory like /usr/src/.
Configure() would change into the correct directory before running the configure script. The output of ./configure is piped to a piece of code that checks for error messages. If Bleeding Edge detects errors to do with dependencies, it can search the Apt database for the missing dependencies, and then ask the user whether they want to try installing them. This is really to provide a means of debugging the script for the packager, and intelligently handle any human error that may occur at that time.
Make() would probably have to have its output directed to a file, and then have the file scanned afterward for error messages. Make's error messages always have the same form, so it would be easy to spot. The user could be told that the package failed to install, if a message was encountered. Otherwise, execution would move onto the next step.
Debian_install() simply uses Checkinstall to install the package. But the packager can choose to supply keyword arguments which will tell Checkinstall what information to put into the package, such as "maintainer" (shown here). But what's this? Checkinstall would automatically put "beta" as the package version - dpkg will not allow this, so Checkinstall would fail. However, Bleeding Edge is smart enough to know dpkg's rules, and will prompt the user to choose a proper version number (suggesting 0.9 as the default for "beta").
If we were on an RPM based system, the debian_install() function would not be called, and instead the rpm_install() function would run. I have no idea if an alternative to Checkinstall works for RPM systems, so I'm hazy on how this particular link would work.
See what I mean? This is a simple example and easy to write. Yet, it provides a lot of opportunities for error correction. For installations like Firefox 2, where you need to move files around to get the software to compile and run, Bleeding Edge would provide safe interfaces to the mv and rm programs (so files can be moved back to their original places should the package be uninstalled). Also, distro-specific parts (like specifying the location of Lua for installing Aleph One on Ubuntu) can be handled without confusing the other distros, because Bleeding Edge will not run parts of the script that are inappropriate.
Best of all, you can get up-to-the-minute software for all architectures, without dependency hell and without going to the command line. The finished package is optimised to your system and registered with the native package manager. Unlike other packaging formats, the installer script which runs as root is human-readable, so you can check that it's not malicious. A package would only take up the same size as the source code (plus a kilobyte or two) and you can even use the system to install binaries!
I'd love to get started on this system for Copland 1, and introduce it to other distributions, but I still have to finish Copland 0 first! I hope hope hope that I can do the latter very soon, and that I get a number of programmers to take on the load of creating other programs so I can work on Bleeding Edge.