Shawn Walker wrote: > On Feb 6, 2008 10:31 AM, Kyle McDonald <[EMAIL PROTECTED]> wrote: > >> Shawn Walker wrote: >> >>> Yes, I am trying to say that packaging is the issue here, not software. >>> >>> >>> >> No. Dependencies are the issue. Many dependencies are created when the >> > > Dependencies are a result of packaging in most cases, so I don't see > how what you are saying is much different than what I am saying. > > I'm fairly certain we're effectively saying the same thing. > > No you're missing the distinction (it may be fine, but it's important.)
Hypothetically, Say you're creating some new modular administration tool for all of Solaris, You're thought is to make it web based, and write it in PHP, and use Apache to have it run by default. Serious thought needs to go into whether or not you want basic installs of Solaris to now be *forced* to install Apache and PHP. Alternatives should be considered. Or You're integrating some new feature that you have to have a newer version of Perl than is in Solaris already. Do you just add a second or third version of perl to solaris for you're project? Do you work hard to find a way to get what you need in the existing one? Do you campaign and help to get the other features that use the older versions to move up to your version? Do you Punt on Perl and go back to C? I don't know what the right answer is, but I know I'd hate to end up with 3 version of Perl on my machine. Some base things need to be defined as 'base Solaris' building blocks, and the code for other software allowed to depend on being there. It should be a rare exception that an optional piece of solaris is allowed to require a part that isn't one of these basic blocks. I doubt one group of blocks could be made to work. However, I think a layered set of multiple groups of blocks could be designed so that exceptions would be very rare indeed. But tought and engineering needs to go into this list of goupr of building blocks needs to be available when projects are being planned and coded, not just when they are packaged. > I wasn't suggesting packaging technology was a solution to this. > > Oh. My misunderstanding. >> Also I think most dependency problems that can be fixed by re-packaging, >> can be fixed today with the current pacakging tools. It just takes a >> finer resolution of packges, and likely an explosion in the number of >> packages. The problems in the packaging, and the problems being solved >> in the packaging tools I think, are largely ( though maybe not entirely) >> orthogonal, and unrelated. >> > > Didn't I just say the problem is the packaging? > > I was trying to add that I believe fixing packaging boundaries, and dependencies is a higher priority than new packaging technology. Enough so that a coordinated examination and effort (Is there one already?) across all of solaris would be a good idea, rather than leaving it to the different projects to realize the limits of their current pacakges, and fix them at their own pace. -Kyle _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
