One of the big problems with the existing packaging system is that much of the information needed to maintain coherence in an installed system is kept outside of the on-disk packaging format. The packages do not contain any information about the context into which the package can be installed, etc. All this information is kept in external files, and maintained by hand.
Some particular examples include the pkghistory file, clustertoc and the plethora of scripts and processes maintained by release engineering to insure that different packages do not deliver the same files, that all packages agree that /usr/lib is a directory, etc. Today, we don't even generate package dependency information automatically; Solaris package dependencies are lovingly handcrafted by skilled software artisans. It is our (those of us actively contributing to ips) goal to insure that ips is complete and fully automated; that no additional tools, scripting, databases, armies of clerks or other out of band mechanisms are needed to generate a coherent set of packages that can be used to generate and upgrade Solaris images. An example might help: two packages end up exchanging files in a build; eg A.1 contains X B.1 contains Y A.2 contains Y B.2 contains X This generates two (perhaps optional) dependencies: A.2 requires at least B.2 B.2 requires at least A.2 Without the previous history of both packages, it is impossible to determine that this dependency exists. If we are to realize our goal of full automation, we need to use a repository as the means of software publishing. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
