Matt Williamson wrote: > Dave Miner wrote: >> Peter Tribble wrote: >>> On Wed, 2006-05-31 at 23:56, Dave Miner wrote: >>>> First, I'll acknowledge that the outline as written certainly >>>> accomplishes the basic requirement of providing a replacement for >>>> usage of tarballs or other relatively unstructured software >>>> distribution mechanisms. >>> >>> What have we got against tarballs? I would regard that (or maybe >>> in fact a zip or jar archive as that's more portable and has an >>> established scheme for supplying metadata) as perfectly adequate - >>> in fact, I would much rather have an archive I can simply extract. >>> >>> What problems are there with simple extraction of files that are >>> seen to be in need of a solution? >>> >> >> I don't have a problem with tarballs, James or someone else can >> explain why they don't meet the requirements they've identified. >> > > This one is not met by using tarballs. > > - Remove barrier to using native packaging on Solaris. Many > software vendors spend effort producing parallel distributions > not based on Solaris packages, or do not produce package-based > distributions at all. This requires the product group to re-invent > technology already available in the packaging tools. > > I will expand on this for the community. We have a large number of > products in JES and across the company who are releasing the same > software in two formats on Solaris, zip distros and packages. This is > pretty costly to Sun from a development, testing, support, patching, > update and sustaining perspective. It also adds confusion to our > customers as well. They may now have to now try to manage those > duplicate distributions. > > I can see clearly how this is making this situation better: > - Common distributions for testing, development, deployment. > - Pkg database > - Common patch format to allow updates > - Backout of pkgs and patches > > I have seen it argued that one issue with the proposal is that now the > "Adminstrator" has lost control of what's installed on users systems. > With zip distros they have less control don't they? The current > customers we have using these distros haven't seemed to mind too much > about them until now. >
No, I didn't say they "lost control". But the proposal is only a bare minimum replacement, and provides no additional control where it seems it would be desired. We need to anticipate what customers next need will be, not just what they've complained about in the past. And if everyone was actually happy with zip distros, then why do we need the proposal? You can't have it both ways. > Don't get me wrong, I do believe that better software management tools > are needed for Solaris, including in the packaging area. However I don't > believe that this proposal is the wagon that those should be hitched. > I'm pretty unmoved by this; at some point you have to take action to help manage the increasingly complex range of options introduced. Failing to address it at the time you increase the complexity is merely a false economy by cost-shifting that's usually exposed later, and remedied at even greater cost, with less flexibility. Dave
