[wpkg-users] [Bug 183] Downgrade should fall back to Upgrade when no downgrade rules exist

[bugzilla-daemon at bugzilla.wpkg.org]

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

Rainer Meier <r.meier at wpkg.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |r.meier at wpkg.org
         Resolution|                            |WONTFIX

--- Comment #2 from Rainer Meier <r.meier at wpkg.org> 2010-05-03 20:55:42 CEST ---
Either this has been discussed in bugtracker or on mailing list or I had it in
mind already and I was just arguing with myself whether to implement such a
thing or not.

Unfortunately the end of the story was quite clear. Such a "magic" automatic
selection of commands (user clearly did not specify any downgrade/upgrade
commands but WPKG just selects some commands on its own) would be very
dangerous.

A lot of existing packages would behave wrongly since upgrade and downgrade are
clearly some independent and unrelated things. I agree that for some software
packages upgrade and downgrade commands are identical. But for most software I
know it's not. Downgrade rather requires removing and re-installing.

Sure somebody might argue that in his case all applications use the same
downgrade procedure as upgrade procedure. If WPKG would automatically generate
commands it's clearly doing something unexpected which can cause problems. I
know users (in the office I work for) where users sometimes upgrade
applications by themselves. WPKG detects this and would perform a downgrade,
but since there are no downgrade commands it's just reported that the software
is not identical to what is expected on the system. Such setups would simply
not be possible if WPKG would automatically run some upgrade commands in this
case.


So if such a "feature" would be implemented it would clearly disallow a
perfectly valid use case (not specifying any downgrade commands on purpose).
Stating that somebody could in this case just specify a "noop" downgrade
command which does nothing is not valid since it would require all users (the
bigger part of WPKG users presumably) to change their packages to prevent WPKG
doing something which they anyway never asked it to do.


I would rather vote for a different solution. If you're using WPKGExpress or
any other GUI it could be an enhancement request to such a GUI to offer a
checkbox to use the same command for upgrade and downgrade while it creates the
necessary XML structure in the background. Alternatively it could propose the
upgrade commands when specifying the downgrade commands.

If you're not using any GUI how much time does the copy of one line XML take
you?

So please try to think about the "big picture" and you will realize that such a
feature would break existing packages and enforce sysadmins to think about this
special feature for each package they build. Instead of behaving the expected
way (do not execute downgrade commands if none are specified) it would just run
commands which were never specified.



I perfectly agree that changing this behavior is very simple since WPKG can
easily check if there are some downgrade commands and if the list is empty it
fetches upgrade commands. Probably a three-liner. But I do not agree breaking
the behavior for existing WPKG users just for a "convenience" functionality of
some sysadmins which might not have thought about the consequences which can be
much worse in some cases if WPKG just runs some commands instead of just doing
what it has been told to.

Feel free to keep your patch and provide it to others - or refer to this report
to get fetch it. I also thought about a switch to enable/disable this behavior,
it might be an attribute of the package but I think it's quite useless. If
somebody can think about setting an attribute which allows downgrade/upgrade
commands to be substituted one could also simply copy the commands in XML.

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