Martin Man wrote: > Stephen Potter wrote: >> Peter Tribble writes: > >> >>> 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. > > I can guess what -devel does, but I can't see what 'r' and 'u' are, > thanx for explaining that m = man and h = header ;-) Are we still in 8.3 > world? Probably, with half of the filename being eaten by SUNW ;-) >
Long ago, package names were limited to 9 characters. Thus the names were quite terse. >>> 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. > > splitting into -devel is good IMHO, because > > 1) users don't need gcc and header files and static libs > 2) developers can always install them > 3) it saves space, and yes, space is still important as it was before > even if we have bigger drives and more memory -> think Java vs. flash, > or Linux live distro on USB flash drive > As Darren pointed out, we don't bother with static libraries anymore. The space required by header files and other developer-specific items in the current Solaris WOS appears to be essentially in the noise, though I haven't studied it in great depth. The problem, at this point, with increasing the granularity of packages is that we don't have automation for determining and maintaining package dependencies, and we know we're not good at maintaining this sort of thing manually. We're working at some solutions, but until we actually have a solution in place, we'd prefer to avoid making the problem worse. Dave
