[Dropping smf-discuss; this doesn't seem to have much to do with SMF.] Paul Kraus writes: > On 10/25/06, James Carlson <james.d.carlson at sun.com> wrote: > > > 1. Core Solaris software tends not to have a complete list of > > dependencies in the packaging database. Instead, testing relies > > on the supported metaclusters (reduced networking, core, user, > > developer, entire distribution). If you add or remove packages, > > you have to be very careful to get the dependencies right. > > This is a major annoyance I have had with Solaris for > years.
No doubt. > The SysV package spec (which is what the Solaris Package is > based on I believe) as well as the Solaris Package spec include > dependencies, why aren't they all in place and correct ? Linux seems > to be able to get this right with RPMs. Also, the pkg* tools do not > provide a 'recursive' option to take advantage of the dependencies. > > Is this lack of complete dependencies in the packaging > intentional on Sun's part, or just many small oversights ? Are the > OpenSolaris packages any better ? Though it seems like a simple question, there isn't just one answer to it. Have you read Dave Miner's document about packaging and install? It may answer many of your questions. http://www.opensolaris.org/os/community/install/files/install_strategy.pdf In some cases, yes, it's an accumulation of oversights. In comparison with all the other tasks that a Solaris developer must contend with -- documentation, technical reviews, coding, test development, bug fixing, and so on -- packaging can be a fairly arcane art. There are an intersection of multiple different complex and not- widely-understood technologies that conspire to make things difficult. Not many developers fool around with systems that have a separate /usr partition, but this is supported by packaging. Nor do all developers make use of diskless, flash archives, patching, jumpstart profiles, package clusters, or even Zones. Each of these has an impact on how packages are constructed, and the effort involved is often quite tangential to producing a new FooBar feature on schedule. Then there's the paucity of tools. Even if you get it right once, any non-trivial project will be subject to future maintenance and changes, and those can break the dependencies, and there's no way to find this out. This is something I've seen go wrong in Linux as well, so it's a common problem. (I eventually just gave up on Debian because I ended up in a tangled jungle of apt-get dependencies that never did resolve right.) And then there are the sort of complex dependencies to which software is fated. In some cases, an application will be dependent on some other service, but only if a particular configuration flag is set or some particular usage scenario is encountered. Is that a "soft" dependency? And how does the packaging system know or care about application-specific configuration? Finally, there's the test matrix problem. With over 1000 packages, can anyone really think that all 2^1000 possible installs will be tested? Then factor in patching and upgrade to each of the subsequent supported releases for each of those mixed-bag of selected packages, and the merely ludicrous becomes incomprehensible. If we're not testing what we promise will work, then what are we delivering? I think it's a pretty deep problem, and I doubt that "please add more things to the depend(4) file" will actually result in a substantially more usable system. > Sorry if this sounds like a rant, but this is one of the very > few areas where I think the Linux community has done a better job than > Sun. That's possibly true. Though, really, after having suffered through both, I'm not too wild about either, though I favor Solaris's upgrade- it-all approach. -- James Carlson, KISS Network <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
