On Thu, 2006-05-04 at 00:31, Mike Kupfer wrote: > >>>>> "Peter" == Peter Tribble <P.Tribble at herts.ac.uk> writes: > > Peter> To me, package boundaries should be defined simply in terms of > Peter> what makes sense for the end user or administrator. > > Okay, but how do you define "what makes sense"?
That's a fair question, and I suspect that you would get as many answers as people you asked. I'm going to use "user" as shorthand for end user, administrator, customer, or whoever else might use Solaris. First the general philosophy. I would start by describing a package as a self-contained group of files delivering useful functionality to the user. Files should be grouped into packages according to their functionality, not according to how they were built, or to their place in the directory hierarchy. Effort should be made to reduce the number of packages, as every extra package makes it harder for an administrator to manage their system, increases the diversity of system configurations, and slows down administrative operations. The current way that Solaris is split into packages largely violates the 3 principles above. Some of this is due to build structures leaking through; Rainer's proposal is a clear example of this. Some of it is the use of multiple packages to meet other goals. For example, the root /usr / share split; or creating separate packages to ease zone installation. In both cases I regard this as an unfortunate mistake - new mechanisms should have been created rather than abusing the packaging system. (If not classes, another similar label; or an additional structure alongside regular packages.) In some cases, we have separate -devel or header packages. But we're inconsistent there - sometimes we follow the devel notation, sometimes we tack a h on; sometimes the man pages are lumped into devel, sometimes into share, sometimes lumped into a large manpage package. Is it, in general, useful to split out the development components? My own experience with this in the past (and usually with Linux systems) is that splitting out the development components - by which you normally mean header files - creates nothing but trouble. There may be cases where a development package includes a set of tools that you wouldn't normally use, but I can't think of many. Let me move onto some examples. Consider BIND. This is delivered in 2 packages - SUNWbind and SUNWbindr. Now: - There's no reason to split out SUNWbindr. It only contains the service manifest. There may have been cases in the past where not installing the rc script might have been useful, but if the software is installed then so should be the manifest, and SMF used to enable or disable it. - Both server and client tools are supplied in the one package. If one were to consider splitting this up, then into client and server components would be the only sensible split. (But even then I would just install everything and rely on the manifest to control whether the server is enabled.) Consider png. This has the main package, and splits out the header files and manpages into separate packages. That's 3 packages to manage instead of one, for little gain. This pattern is repeated across a lot of packages - why does gimp take 5 packages? (And why doesn't the package name call it the gimp?) The excessive splitting isn't universal. SUNWlxml and SUNWlxsl, for example, only add one package. So it's obviously not necessary to split a library up into multiple packages. Some applications get split up even more. Mozilla takes 14 packages on my machine. I see no reason why 1 isn't entirely sufficient. Looking at Solaris proper, there are 3 problems I have: the first is the number of packages that are necessary to support fibre-channel (over and above the actual drivers for various devices); the next is the separation of certain drivers into their own packages; the third is the number of packages just to deliver a simple driver. For example, why should ce be delivered as a separate package at all? And why should it need 3 packages? There are slight differences between sparc and x86. I would tend to deliver 3rd-party drivers (ie. those drivers obtained from a 3rd-party supplier) in separate packages. So I would certainly put a lot of Sun's drivers directly into core Solaris. I don't really see any benefit to having eri as a separate package, or ses. It would simplify installation and upgrades and a lot of administrative tasks if you could assume that all the drivers for standard hardware configurations of the desktop and volume server products were always present. One way forward is to treat clusters as first-class objects, and this is necessary. But simply declaring that the package problem can be solved by using clusters simply isn't true. Clusters should be a level above packages, designed to group a number of software products together. For example, gnome would be a natural cluster. The SAMP stack would be a natural cluster. Using clusters to try and solve the problem of needless proliferation of packages has at least two critical failings: - it confuses the user by using the same notion (of a cluster) for 2 differnet meanings - it essentially says that the packages structure is completely useless and meaningless: elevating clusters to first-class objects shouldn't degrade packages, or encourage the creation of badly designed packages. -- -Peter Tribble L.I.S., University of Hertfordshire - http://www.herts.ac.uk/ http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
