Kyle McDonald wrote: > Dave Miner wrote: >> >> The answer is that, no, there really isn't any reasoning behind it. >> The CATEGORY field contents are a fairly arbitrary classification >> system, I don't think they're audited in any meaningful way, and I >> wouldn't consider them to be particularly useful in maintaining the >> system. The "-Y" stuff in pkgadd is probably more an old AT&T System >> V-ism than anything, though I do note that some consolidations (JDS) >> appear to make more use of it than others. We certainly don't have >> any rules about dependencies between categories. >> > Hi Dave, > > Irregardless of fixing or using CATEGORY, I think Sun would benefit > greatly from organizing and fixing the package dependencies in Solaris. > I know it's a known problem, but I'm surprised at it's relatively lower > priority. >
We agree that it's a problem, but we're looking for solutions which do not involve developer-maintained dependencies; that's how we got to the state where the current dependencies are poorly understood and expressed and thus basically useless, so a different approach is needed. But there are other deep problems in packaging which are also important and need to be solved as well, so we'd like to consider them together, rather than separately, as being able to change assumptions sometimes makes an intractable problem suddenly simple. > I would think that having a package organization like this would really > help so many users who are new to Solaris(read: usability and > approachability) > [View with a fixed spaced font. :)] > > > > <-- Management Apps --> > <- DS1 Apps -> < Misc Desktop Apps > <- DS2 Apps -> <-- Management > Framework --> > <- Base Desktop System 1> < Base Desktop System 2-> <-- Cmdline > and Server Applications--> > <----------------- Window System -----------------> <-- OS Options --> > <-Network Services------> > <------------------------------------Base Operating > System-------------------------------------> > > > This may need expanding, but the concept is there: Basically packages > should only be allowed to depend on things within thier 'group', or in > 'groups' *Below* them. Dependencies to packages in peer groups or groups > above them shouldn't be allowed. > I think such a breakdown is flawed over the long term, especially if we wish to acquire packages more or less intact from other communities who might have a different decomposition. Architecturally, we'd prefer to leverage rather than re-invent in many technology areas, and a rigid package classification taxonomy and use policy that works against that seems doomed. It's too much cathedral, not enough bazaar, as far as I'm concerned. > > For Example: > > I should be able to leave off all of the WBEM management stuff, without > losing the ability to run a DHCP or other boot servers. > I should be able to load only a base Xserver with a screensaver, and > leave ALL Desktop systems like GNOME or CDE, and all Graphical > Applications like Evolution. > I should be able to load the graphical login screen for the Xserver, and > install only GNOME, and not any part of CDE. > I should be able to install the base GNOME session/window managment, > panel applets, etc. without needing any particular Application installed > like Evolution. > > These are only examples. There are probably more. > > I know it's not an easy thing to do either. Since I bet fixing this > would mean splitting some packages into multiple parts, and putting > those parts in different groups. > I think it'd be worth the effort though. Especially when I hear talk of > reducing the ability to select/deselect individual packages in the new > Caiman installer. If you do want to limit the installer to larger higher > level groups of packages, those 'groups' need to be organized in souch a > way that they only 'build' on groups they need. With the package > dependencies the way they are now, any higher level selection mechanism, > is going to force basically everything to be installed. > It's a requirement that we provide a better dependency discovery, resolution, and maintenance solution in the packaging for Nevada. We may also provide fewer choices in the installer. But there will be a lot more discussion of any proposals for either one through this community before anything is implemented, and they will certainly be required to make sense when considered together ;-) Dave
