Nicholas Solter wrote:
> Bart,
>
> I'm not following why you need to capture user intent in the scenario
> you outline. The two situations should be distinguishable from the
> package installation history alone.
>
This was the piece we were missing until recently; we didn't record
user actions. We would still like even better specification of intent
to facilitate upgrade (eg suppose user had netscape installed, does that
means he wants firefox now?).
> Alternatively, couldn't we have a flag to uninstall that says that the
> metapackage and all packages on which it depends should be uninstalled?
>
> Stepping back, what's the timeframe for implementing a solution to the
> uninstall problem? In the product that Ed mentions (Sun Cluster) we're
> going to easily have 30 or 40 packages. We really don't want the user to
> have to specify each package explicitly in order to uninstall
> clustering. Any guidance on a workaround? What do you think about Ed's
> suggestion of a "removal metapackage?"
Well, clearly you could also use the name space to do this; we can get
pkg uninstall 'clustering/*' to work a lot sooner than defining new
types of versioned dependencies that uninstall correctly even though
they depend on each other. Right now wildcarded uninstalls don't work,
but that can be fixed pretty easily.
Right now, we're just finishing 2008.11; next is (incomplete and
in random order):
1) fat (multiple architecture, i18n, devel, docs) packages
needs package facets
2) get sparc repo up and sparc booting on opensolaris
3) enhance transport to use http get so regular apache services &
cdns work
4) redesign publication to support publishing against incorporations,
publishing from proto area w/ manifests, adding more automated
dependency analysis. Make it possible for ON developers to
directly produce IPS packages....
5) redesign package installation planning (SAT solvers?) to
handle complex dependencies correctly. This is a hard problem,
and needs much better technology than we're currently using.
6) get various SMF services configured to handle updating various
editable files
I guess what I'm saying is that we know we need something, but
since there are reasonable workarounds for this problem right
now, facilitating the uninstall experience is not at the top
of our list.
-= 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
