Now to the extent that a particular application is not overly dependent upon tight system integration I imagine that Autopackage can be a useful inter-distribution distribution mechanism. Yet it is exactly the lack of system-wide integration in Linux applications which people are constantly complaining about: and this integration is only currently possible via linking "policies" with other libraries and this requires specific compilation options and/or patches neither of which can be adequately addressed by Autopackage due to the differences in the distributions themselves. Steps are being take to abstract some of these issues to facilitate wider-scale system integration without resorting to specific compilation options and patches: dbus, hal, shared-mime-info etc. but they are still new developments. To the extent that small libraries and daemons can provide a richer context of system integration-ie. provide "hooks" for applications to make use of to effect integration the more useful something like Autopackage becomes.
The situation is improving all of the time but we still face issues concerning which local email system(sendmail, qmail ?) is installed by default, which sound system is being used by default(ALSA, OSS, arts, esd, jack ?), which printing system(CUPS, Omni, LPR ?) is installed by default etc. In fact a myriad of micro-libraries have been written to render each of the interfaces offered by such basic-system services compatible with one another-introducing another layer of dependency issues, eg. alsa-oss.
Recently I took a look at Zeroinstall and was quite impressed by what I saw. It seems to me that a combination of Autopackage and Zeroinstall might form important parts of a potential "solution" to dependency hell. Yet there seems to to still be a missing element: autobuilding of software form source.
IF the distributors and software developers could agree on package naming conventions and something like pkgconfig(or maybe pkgconfig itself) itself was universally used to index all available software already installed on the system, and distributors would not patch their sources in ways which break compatibility between libraries-and document those cases where they do in such a way that the system "knows" about such incompatibilities(ie. like a pkgconfig file which ascribes a version number to a package which precludes it from being used by applications expecting different functionality)-and this is a mighty big IF- one could then implement a background autobuilding environment(sandboxed of course) to quickly compile any specific libraries which are still outstanding.
Of course I won't go into the details of how utterly horrid the build systems are in some of the best known distributions: but if their was a law against insane build environments which have been hacked together beyond mere mortal comprehension Redhat and SuSE would be punished for life in compilation purgatory ;). (Notice how I have not mentioned Debian here-although I do not use Debian I truly respect the quality build environment which Debian has created-which is probably why Debian is used as the basis for so many distributions.)
My idea (but perhaps not mine alone?) concerning a autobuilding environment looks like the following: a user wishes to install an application, this application is dependent upon a set of specific libraries further specified by unique version numbers. Of the list of dependencies only two are found that are not offered in that version by the distributor themselves. Because the operating system "knows" this "automagically" through rigorous adherence to effective "documentation" of installed libraries(ie. via pkgconfig) including "incompatible libraries" (ie. crippled and lamed libraries which only have a use in the specific context of that particular distribution and that particular distribution version number) and naming conventions (major.minor.bug.distrofix), the system could "automagically" initiate compilation of said libraries from source, silently, so as not to bother those frightened by gcc. The issue I see involved in such are:
How would the system "know" which compilation options to use(ie. which can it use safely and which may cause other dependency problems.)? If the distributors would encode their build environment specifics in some kind of machine readable configuration file which specifies which options were used when compiling each library and specific versions of specific patches used in the compilation-these factors could form the "knowledge" of the autobuild environment.
What kind of works needs to be done with ldconfig to enable "slots" and differentiated dynamic loading of specific libraries for specific applications: ie. the system should easily facilitate multiple concurrent version of installed libraries which are incompatible with each other and dynamically choose which it needs at run time? (Gentoo already has this).
- "Dependency Hell, Page 1/3"
- "Dependency Hell, Page 2/3"
- "Dependency Hell, Page 3/3"
