Previously Raphael Ritz wrote:
> Tom Lazar wrote:
> >there is, however, one issue i'd like to bring up, namely if it would
> >be a desirable behaviour, if uninstalling ProductOne would also
> >uninstall ProductTwo. since there is a current trend of 'exploding'
> >products into smaller, re-usable components i could imagine that quite
> >a few users might get frustrated when they install a product 'just to
> >check it out' and that then populates the list of installed products
> >with several dependencies which they then need to de-install manually.
> >two weeks later nobody will remember what ProductTwo does or how it
> >got installed.
> >
> >any ideas on this?
> >
>
> while I think I see your point I would be against making
> that the default because it could easily break in situations
> where you have multiple cross dependencies. Like product
> A depends on B but product C also depends on B. Then
> uninstalling A will break C (you can take that further if
> you like). Keeping track of those kinds of dependencies
> to do the right thing on uninstall might be tricky.
Automatic uninstalling is probably not the right approach. For Debian I
once came up (and this was added to apt 10 years later) with the concept
of marking packages as automatically installed when a user does not
install them by hand but they are pulled in as dependencies of another
package. The packaging system can then do an analysis to see if there
are installed packages that are marked as being automatically installed
but which no other installed package depends on. If so you can tell the
user that they can be safely removed. In the command-line interface that
looks like this:
snow:/home/wichert# apt-get install gnotime
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer
required:
squid-common
Use 'apt-get autoremove' to remove them.
> On the other hand it could be convenient to offer it as
> an option in the UI to list the dependencies on uninstall
> and to ask whether they should be removed (or which ones).
> But for this to be helpful the quickinstaller would still need
> to maintain a dependency matrix for the above mentioned
> reason.
There are enough utility methods to figure that out: QI has some methods
to determine which GS profile belongs to a package and GS can give you
the list of dependencies for a profile.
> >also, there's this paragraph in the plip that i don't understand:
> >
> >--snip--
> >One possible problem is that GenericSetup will only warn if a
> >dependency is missing. This means that if a required product has not
> >downloaded and installed in the instance by the user he will not get a
> >proper error message.
>
> What's not clear? A warning isn't an error meaning GS
> will happily install a product even though a dependency
> might be missing. It will issue a warning (in the event log)
> but who cares about warnings ;-)
It's a warning users will never see. CMFQuickInstaller should not offer
to install a product if its dependencies are not installable. I'm
not sure yet what the right behaviour for GS is here.
> Obviously the product will be broken in such a situation
> therefore it would be better for GS to fail and raise an
> error instead. But this is GS territory where we are more
> on the user side. So maybe we should bring this up
> on zope-cmf? I assume Tres or Yuppie might have an opinion
> here as well.
The relevant code in GS isn't designed for that right now but that
should be quite easy to change. In fact I'll probably need to do that to
anyway since it makes sense to have the support methods for that in
GS rather than in QI.
Wichert.
--
Wichert Akkerman <[EMAIL PROTECTED]> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
