http://bugzilla.wpkg.org/show_bug.cgi?id=94
Rainer Meier <[EMAIL PROTECTED]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[EMAIL PROTECTED]
| |t
Status|NEW |ASSIGNED
--- Comment #4 from Rainer Meier <[EMAIL PROTECTED]> 2008-01-08 23:30:23 ---
I see that a dependency-aware removal could be helpful. However it is only
useful in case of manual package handling (i.e. manual removal). Automatic
handling (synchronization) already takes care about the dependencies (at least
at installation).
However reverse-dependencies are a bit harder to trace. Remember that we do not
have to trace the package dependencies (i.e. the package which the package to
be removed depends on) but the packages which depend on the one to be removed.
This could lead to a whole tree of packages being removed when removing a
single package (all packages which depend on the one requested to be removed or
any of the packages selected by recursion).
I even think this would not be too much complicated since I even will not have
to track "limit" the number of uninstalled packages. WPKG can simply remove all
packages depending on the one to be removed or the one depending on these
packages... (recursively).
Of course this could break away quite a huge part of the package tree when
removing an important package but installation/synchronization will immediately
re-install it as soon as the package check of any package depending on the
manually removed shows that the dependency is not installed any more.
I also think that there should be no additional /deps switch due to two
reasons:
- If a package depends on one to be removed then it can be assumed that it will
NOT run without it at all. So it's safe to remove it. Even packages depending
on that 2nd level package will most probably fail to work after that so it's
safe to remove them as well. In case a package dependency is "optional" then
nobody would specify a hard dependency but just add the packages one-by-one to
the profile.
- Using another /deps switch will increase complexity and most users will not
use it at first try (because nobody will look for such a switch in advance).
With the result that the dependencies are usually not removed. Once the removal
has been executed there is no way to re-execute it without re-installing and
another manual uninstall invocation. In worst case I would introduce a /nodeps
switch but I don't like this idea because it can lead to broken dependency
structures by removing a package which is required by others - and this is
exactly what this patch is going to fix.
So let me think about...
I will think about the implementation.
--
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
-------------------------------------------------------------------------
Easy Software Deployment >> http://wpkg.org
_______________________________________________
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users
