James Carlson wrote: > The part that has me unsold here is the idea that by enabling (and > encouraging) this use, we're not just burying ourselves deeper. > > Suppose we did take a step back and looked at the larger problem -- > i.e., how multiple instances of packages can relate to each other and > refer to dependencies on other repositories of software; the same > problem that has plagued diskless, Zones, shared software, and other > efforts in this area. > > Would the solution we come up with look a lot like this? If it seems > unlikely to look like this, then what sort of transition are we > setting those customers up for when we finally do get this right? >
That's a good question and I'm not sure we've accurately characterized it. In my opinion, if there is more structure and definition to a user's software area, as opposed to a random collection of un-tar'd archives in $HOME/pkgs, then the transition to some newer, better structured software management system seems like it would be easier. In that case, your collection of software is somewhat instrumented with metadata that can most likely be mapped to the new thing later on. > It seems like an incomplete solution to me, and doesn't seem to have > much to recommend it over just doing what people already do today: > ship tar images and custom install scripts. > I believe it removes some entropy from the system when used over tar files. I agree that it is not a complete solution, but we are trying to address a pressing need, while not painting ourselves into a corner or making the transition to a later thing more difficult than it already is. We are also trying to maintain the features that customers like, such as the ability to audit, patch, and backout patches against their installed stacks. -jhf-
