turn it inside out
Lots of distribution have utilities (ie /usr/bin/install) that makefiles call to do parts of installs. Why not make an install-like utility that performs that action, but follows distribution-centric and evolving community standards for finding what to install? Check out this made-up description.
Usage: app [-iueb...] directory/tarball [-o[what]=[filename]]
Operation: the first option is -i install, -u update etc.
The second option specifies the source directory.
The third option is for making native packages ie [-orpm=foo.rpm],
or just -orpm
First, app scans the directory for meta-information files and consolidates it. The canonical meta-information file is meta.xml, following some DTD. Other meta-information files are %spec, etc.
For packages with no meta-info - most of the packages out there - the package is compiled using configure; make (with the user watching - ie user sees README, then is prompted for the compile command, defaulting to "configure; make")
Then app scans the files in the directory, compares it against the meta info, and ends up with lists of binary files, shared libraries, modules, plug-ins, icons, daemons, desktop menu categories, users (for subsystems like sendmail), log files, etc. etc. etc.
At this point, if app needs to ask the user, especially about where they want thier icons, whether they really want to place new files in /sbin, it can do so. Implementations of app need to *save the answer* to be used in future installs by the same sysadmin, to share compile setups between users and automate the building of native packages for distribution makers.
Then app does all the adding and copying and package building required by above.
Distributions could do implement this however they wanted. This could be a shell script on a floppy linux that does not actually understand any XML info or be a helper application for my web browser thats unpacks the tar.gz file, interact with the user via a fancy GNOME application. Distributions could make an "app" clone that had plugin capabilities for package formats (reading in place of "directory", and building)
The keys are:
- "app" does not mandate a package format or a directory structure. Well-defined and common ones formats/structures will inevitably be well-handling by each distributions' configuration of "app"
- all build processes should be in a sandbox. There should be one and only one piece of software responsible for getting the built files placed into the OS environment correctly.
- a log of installation should be reusable and possibly sharable.