[wpkg-users] [Bug 114] new parameter /force2 ?

[bugzilla-daemon at bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=114





--- Comment #8 from Rainer Meier <r.meier at wpkg.org>  2008-05-08 22:17:18 ---
Despite the fact that we are running off-topic (initial request was to discuss
about a feature to remove installed packages which should not be there) I see
some real issues when implementing something like an additional
action="upgrade" attribute to checks.

First of all the current architecture does not allow such kind of checks. But I
don't want to say it's not possible. It just needs some more careful design
while I am not sure if it's worth the effort. In fact we are clearly talking
about broken installers here which do not upgrade silently when a previous
version is already there.

In addition your new proposal here is somehow incompatible with the proposed
/checkUnassigned switch. If the /checkUnassigned switch would check the install
status using the new <check.../> syntax then it probably would receive the code
for "upgrade" which means "this package is already installed but it is
outdated". What should WPKG do then? According to the /checkUnassigned
description the package should be removed if it exists but should not be
installed (not within the profile). Unfortunately if the install check returns
this "update" state, then WPKG does not know if the uninstall strings (which
are actually for the latest version on the server) can be used with such a
previous version too.
In general I would say WPKG should not try to execute the uninstall strings but
just print a message to the logs (can be read by administrators to know such a
package is installed on this machine).

More issues/questions are coming up if we think about a generic implementation
of the action="xxx" attribute. This attribute could have the following values:
- install
- upgrade
- downgrade
- remove

but what if a user specifies something like

<check type="logical" condition="or">
  <check type="uninstall" condition="exists" path="Mozilla Firefox (2.0.0.13)"
action="upgrade" />
  <check type="uninstall" condition="exists" path="Seamonkey" action="install"
/>
</check>

In such case the action might evaluate either "upgrade" or "install". To solve
this actions could have priorities like:
1 default (by package version comparison)
2 execute remove
3 execute downgrade
4 execute upgrade
5 execute install

So to me even in theory it looks quite complex and hard to control. In addition
you would need to specify precise checks for each known version of this
application which is a true headache. Quite a lot of effort just to detect if a
package newly added to the profile needs to be upgraded (which would be done
anyway on next package update). In case a package does not belong to the
profile and the /checkUnassigned switch would be used then the package should
be finally removed. Your addition would allow to execute an upgrade instead -
on next synchronization it would be regularly removed.

But again, this is a lot of change with a huge potential for bugs. As you can
see such a change depends on a huge number of constraints while again it is
only useful in some really rare cases where the installer is wrongly behaving.


-- 
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.