Laszlo (Laca) Peter wrote:
On Tue, 2009-10-13 at 15:17 -0700, Bart Smaalders wrote:
It seems as if you're trying to have the low level packages
[gtk2,cups,papi] drive installation of the higher level
ones (gtk2-print-cups,gtk2-print-papi)... this appears
to invert the usual selection logic, which would be to
choose high level packages which install their dependencies.
Right. We started looking from the direction of the higher
level packages and got stuck. The end-user problem we are
trying to solve is that we have a bunch of desktop apps that
can print. In order to print, they need the right gtk
printing backend for the installed printing system. Ideally,
the apps should depend on "printing", which can be either
a group of packages for the cups stack or a group of packages
for the papi stack. The livecd has one printing system
installed. Unfortunately, it doesn't work for everyone,
so we keep telling people to ``install cups''. But if they
do, they still won't be able to print until the also install
the gtk backend for cups.
Group packages are nothing more than packages that do nothing
but depend on others.... clusters in svr4 vernacular.
Ah. Isn't that the same as incorporations?
No... incorporations define a compatible package version
surface, but do not require the package to be present.
An English text version of an incorporation dependency would
depend type=incorporation fmri=pkg:/[email protected]
If pkg A is installed, it must be at version 1.1. 1.0 or
1.2 don't match, but 1.1.1 does.
These allow package publishers to change these packages
as a set, w/o worrying about having incompatible versions
of various related components installed.
- 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
