Stephen Hahn wrote: > * Jim Connors <[EMAIL PROTECTED]> [2008-03-28 19:21]: >> Stephen Hahn wrote: >>> Or take a copy of the source and experiment with some >>> splitting/refactoring. It's pretty easy to break things apart and try >>> out various ideas. >> Minimalists would likely want to see SUNWcs broken up into lots of tiny >> pieces. Yet there appears to be interest in this alias to create even >> larger packages and let filters handle the details. Are these two ideas >> in direct contrast? > > Nope. There are three themes here: > > 1. Break the historically accreted packages up into smaller units > based on feature definitions (or similarities), private > dependencies, and relative rates of change. SUNWcs needs to be > broken up, as it's so big that it (a) makes real minimization > difficult, and (b) participates in lots of SUNWcs <- other package > <- SUNWcs self-loops, which are annoying. > > 2. Combine packages that were split only for reasons of convention. > At present, these reasons are the root/usr split and the separate > packages for multiple architectures. The client handles/will > handle these cases automatically, based on the image's properties. > (Filtering is part of this, although there is also aspects driven > by the image type.) > > 3. Encode the cluster/metaclusters/Mike G's features/etc groupings as > convenient, retrievable group packages. In the current > repository, the slim_cd, slim_install, and redistributable > packages are examples of these. > > I believe these can be pursued consistently: someone pursuing a small > or custom install image would be interested in 1 and 2, but ignore > packages created to satisfy 3. Folks trying to ease installation of a > particular stack of related software are all about 3. I suppose we > could look at 1 and 2 being about the minimal building blocks, and 3 > being about sets of blocks, if Lego analogies are okay... > > - Stephen >
To expand on this, we're talking about combining all related packages for a particular component into a single package, and filtering out pieces you don't want. For example, a package should include docs, binaries, development bits, localizations, etc. Where we want to break things up is where a single package delivers multiple functions or combines multiple use cases. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
