Bug 200978 - Do not leave even disabled modules unupdated which are not compatible with other updates
Do not leave even disabled modules unupdated which are not compatible with ot...
Status: NEW
Product: platform
Classification: Unclassified
Component: Autoupdate
7.0
All All
: P3 with 1 vote (vote)
: 7.3
Assigned To: Libor Fischmeistr
au-issues
: REGRESSION
: 221562 232735 (view as bug list)
Depends on:
Blocks: 191657 199808
  Show dependency treegraph
 
Reported: 2011-08-15 22:22 UTC by Jesse Glick
Modified: 2014-02-10 14:14 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2011-08-15 22:22:06 UTC
After the fix of bug #191657 it is possible for a user who has agreed to accept all updates to be left with some disabled modules in the installation which are incompatible with newly updated (enabled) modules, typically noticeable due to major release version increments. This is unacceptable since they will not be able to turn on those modules without updating them, nor update them without turning them on - a catch-22!

http://wiki.apidesign.org/wiki/Incremental_deployment#Easy_fix may be a workaround for a micro release where the number of updates is small and incompatibilities can be individually reviewed and controlled, but this would not be a realistic option if we wanted to do more significant updates.

One possible fix is to always update even a disabled module when it can be detected that the older version would not be compatible with other updates.

Another would be to make a note somehow in the user directory that the disabled module is due for an upgrade, and in any part of the AU GUI that would permit it to be enabled (directly or indirectly, incl. via FoD), do the upgrade first (assuming an UC is still available which lists the upgrade). Besides being lazier, this may be preferable because it ensures that important updates are honored even when there is no incompatibility visible at the module layer.

Another option would be to simply revert the fix of #191657, and solve the bugs it represents in some more direct way. (The comments in #191657 do not really describe what those bugs are.)
Comment 1 Jesse Glick 2011-08-16 14:10:13 UTC
I consider this a defect. In 6.9 and before you could be assured that if you always agreed to accept updates, then whatever you had in your installation would in fact be up to date. That is no longer true - without your knowledge you can have obsolete and possibly unusable modules sitting around, and when you go to enable them there is no warning that anything is out of date except perhaps dependency errors coming from the module manager. That is a potentially important regression, and the cause of some priority bug in 7.0.1 (which I was unable to locate in BZ).
Comment 2 Jaroslav Tulach 2011-08-18 15:02:09 UTC
> One possible fix is to always update even a disabled module when it can be
> detected that the older version would not be compatible with other updates.

Probably preferred solution, if "it can be detected".
Comment 3 Jesse Glick 2011-08-18 17:11:02 UTC
I am not sure of the details of AU manages proxy module infos, but it may work to run through disabled modules before the update checking for those which _could_ be enabled (i.e. problems.isEmpty()), and then simulate applying the update and check for any which now cannot.

I would hope AU already does this for enabled modules and rejects the update if it would break modules in use.
Comment 4 Jiri Rechtacek 2011-10-14 16:17:07 UTC
Uf, it seems as uneasy to solve this. I'm not sure I can fit NB7.1
Comment 5 Jiri Rechtacek 2012-04-12 12:55:09 UTC
No plan to fix it for now.
Comment 6 Jesse Glick 2012-04-24 20:18:10 UTC
Just ran into this again. I have javahints 2.54.0.19.9.13.21.7.2 installed locally, but disabled since this build is not compatible with the current dev build's versions of other modules (it uses impl deps). 2.55.0.x is available on the dev UC, but I cannot update to it because of this bug.

The only workaround is to uninstall the plugin, restart, then go back to Plugin Manager and install it anew (and restart again since it specifies nbm.needs.restart=true).

I think the same problem would affect any AU module using spec.version.base to manage implementation dependencies on a module in the build.
Comment 7 Jiri Rechtacek 2013-07-16 09:30:48 UTC
*** Bug 232735 has been marked as a duplicate of this bug. ***
Comment 8 Jesse Glick 2013-07-16 15:44:50 UTC
I think another solution would be to change the Enable function so that it prompts to update affected modules first. That way, you can still avoid pestering users with constant updates to disabled modules; if and when they ever decide to reënable them, they will be offered the newest versions.
Comment 9 Jiri Rechtacek 2013-08-13 17:36:39 UTC
*** Bug 221562 has been marked as a duplicate of this bug. ***


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo