On Tue 13 Oct 2009 at 03:17PM, Bart Smaalders wrote:
> Laszlo (Laca) Peter wrote:
> >On Tue, 2009-10-13 at 12:46 -0700, Bart Smaalders wrote:
> >>Laszlo (Laca) Peter wrote:
> >>>Let's say we have the following packages:
> >>>
> >>> - gtk2
> >>> - cups
> >>> - papi
> >>> - gtk2-print-cups (depends on gtk2 and cups)
> >>> - gtk2-print-papi (depends on gtk2 and papi)
> >>>
> >>>Is there a way to express that gtk2-print-cups should
> >>>be installed if both gtk2 and cups are installed and
> >>>gtk2-print-papi should be installed if both gtk2 and
> >>>papi are installed?
> >
> >>I suggest that group packages are the right way to approach
> >>this problem...
> >
> >Not sure what you mean by "group packages". Can you elaborate?
> >
>
> 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.
>
> Group packages are nothing more than packages that do nothing
> but depend on others.... clusters in svr4 vernacular.
Bart and I spoke about this a bit. I see Laca's question as a symptom
of the higher-level "shopping for software" problem, and I think our
cycles would be better spent there-- on improving out metadata about
which packages represent high-level features, and which packages
represent, essentially, implementation details.
If I'm an end user, and I want to print, then dammit, I want to print.
I don't want to know or care about papi, cups, etc. If I go to the
package manager, and search for printing, I should get a high-level
collection of software, perhaps called "Recommended Printing Tools". I
should click that, and then whatever the distro builders think I should
use for printing, I should get.
To make this concrete, consider SUNWfoomatic-db (description is
unhelpfully "foomatic-db"). Unless I work on the foomatic codebase, I'm
pretty sure I don't know what this package is, and it's likely that I
wouldn't want to select it in the absence of other related packages.
But today, searching for printing gets me two dozen results, and it's
impossible to know what to pick.
I think the inverted suggestions idea is interesting, but as Bart hints
in his reply, it's probably pretty tough to get right, and tough to
manage and maintain over the long haul. I'd rather we focus more on the
"shopping" problem and work out which packages are high level features,
and which are just implementation details of other packages, and
make the GUI and CLI consume that information. Just my $.02.
-dp
--
Daniel Price, Solaris Kernel Engineering http://blogs.sun.com/dp
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
