Peter Tribble writes: > 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.
On a similar token, every extra piece of software installed on a system may makes it harder for an administrator to manage their system and slow down administrative operations; so lumping a whole bunch of stuff together isn't always the right way to do things either. In fact, throwing everything into a smaller number of large packages may only solve the diversity of configurations problems. > 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. Consistency is good. I hate the linuxy verbose package naming system of -devel. I would love to see u (user), r (root), h (header), m (man), s (share) and the few other package types used consistently. > 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. A lot of these splits made more sense from a historical viewpoint. I remember the days of Quantum 105M drives and trying to fit everything necessary into less than that space, so that you could still have user files somewhere (other than NFS). I remember creating NFS mounted manpage filesystems to save space. It wasn't that long ago that 4G and 9G drives were still common (actually, in my world, they are still common). About 4 years ago, I remember fighting with some of my users because our standard build grew beyond what 4G disk would hold. We eventually told them tough, if they couldn't at least have a 9G drive, we would not support a standard installation. > - 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.) I'm with you, if only the manifest is in the package, it's pretty worthless. Splitting client/server functionality into SUNWbindu and SUNWbinr would be good. > 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?) Again, consider historical reasons. There was also (still fairly prevalent) a security idea that development/headers and compilers were a bad thing to have on a system because it made it easier to install backdoors and trojan files. If you break into a box and don't have unrestricted access to download anything you want, not having those makes it more difficult. > Some applications get split up even more. Mozilla > takes 14 packages on my machine. I see no reason why > 1 isn't entirely sufficient. I see no reason to have MozillaChat, MozillaMail, and the MozillaSpellChecker on my system, since I don't use those features (in fact, Chat and Mail would be disallowed by policy at my company). Having a single package makes my job as an administrator more difficult because I have to figure out how to get rid of them or worry about fielding support calls when someone uses them outside of policy. > 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. Yep, I can probably agree with you here. It would be nice if there were less driver packages and more things were rolled together. Again, though, why should I have a driver on my system if I don't have the hardware for it? Why should I have to install the hme driver on all my systems, when only a small part of my environment even still supports them (for example)? > 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. No, there are a lot more issues, but clusters and automatic dependency generation/handling would go a long way towards solving many of the problems. > The SAMP stack would be a natural cluster. I think you are taking clusters a little too far. Each of the parts of SAMP may be a good cluster, but in a common three-tier architecture, a SAMP cluster would just be wasteful and more difficult to control. I don't want a database on my webserver and vice versa. -spp This message posted from opensolaris.org
