On 01/11/10 06:05 PM, Laszlo (Laca) Peter wrote:
On Mon, 2010-01-11 at 11:15 -0600, Norm Jacobs wrote:
There are a bunch of packages that look like they would want to be
combined to form a single package with multiple facets. This includes
packages that were split into -devel, -man, -doc, -lib, -{locale}
packages. perhaps also -python24 and -python26. This could also be
applied to other things if the selection of a package (or facet of a
package) can cause the selection of different facets of other packages.
Is it possible to set facets of individual packages or only of the
entire image?
I don't know, but I would guess that a facet is selected for all
packages installed (and being installed) on the system. Perhaps someone
familiar with facets could provide a definitive answer.
If the latter, I don't think it's a good idea to
make -devel bits facets. You shouldn't have to install all
development bits if you only need a few components.
The same can be said for man pages, docs, and other files. I don't like
having several different packages for a component. That's why I brought
up the topic. Ideally, I would install CUPS and SANE and then when I
installed HPLIP, I would get the core HPLIP support, CUPS support, and
SANE support, but not LP support simply by choosing to install HPLIP.
Similarly, If I had HPLIP installed and chose to install LP, it would
add the HPLIP LP support automatically.
Having to go back and add the -devel packages is something that I find
annoying some of the Linux distros like Ubuntu. I would rather trade
some disk space for the convenience of not having to stop my work to
install missing devel bits before I can continue. It's particularly
annoying when working disconnected. If there were an easy way to simply
select {installed}-devel (and perhaps there is), I might feel differently.
I have taken a stab at alternate classifications for packages that are
printing related. Largely, I put the printing related bits under
print/...
Since the basenames are supposed to be unique, it's best avoiding
general terms like "other", "standard" and even "client-commands":
SUNWpc print/client-commands
I'd suggest something like print-client-commands, even though
it's under "print/"
OK
SUNWscplp print/compat-sunos4
maybe lp-compat-sunos4?
OK
SUNWpsutils print/psutils
SUNWmp print/mp
SUNWimagick image/imagemagick
SUNWcups print/cups
SUNWcups-libs library/print/cups
library/print/cups-libs?
OK
SUNWpycups library/print/cups/pycups (this contains both python
2.4 and 2.6 bindings for libcups)
SUNWhal-cups-utils print/cups/hal-cups-utils
SUNWcups-manager print/cups/system-config-printer
SUNWfoomatic-db print/cups/filter/foomatic-db
SUNWfoomatic-db-engine print/cups/filter/foomatic-db-engine
SUNWps print/lp
SUNWpsf print/lp/filter/postscript
postscript-filter or even postscript-lp-filter?
print/lp/filter/postscript-lp-filter would be preferable. They are the
postscript filters that are part of the LP source tree.
SUNWffilters print/lp/filter/foomatic-rip
SUNWfppd print/lp/filter/foomatic-ppds
SUNWa2ps print/lp/filter/a2ps
SUNWippcore print/lp/ipp/ipp-core
SUNWippl print/lp/ipp/ipp-listener
SUNWpapi library/print/open-printing
SUNWpsm-ipp library/print/open-printing/ipp
SUNWpsm-lpd library/print/open-printing/lpd
SUNWprint-monitor print/lp/print-manager
SUNWppm print/lp/legacy-print-manager
SUNWgutenprint print/filter/gutenprint
SUNWhpijs print/filter/hplip
SUNWghostscript print/filter/ghostscript
SUNWgsfot system/font/ghostscript/other
ghostscript-fonts-other
OK
SUNWgsfst system/font/ghostscript/standard
ghostscript-fonts-standard
OK
-Norm
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
