"Some of the pending updates cannot be applied because their dependencies were not met."

That's strange. Can you reproduce this error? I agree that it would be good for developers to get more information than this. On the other hand, we shouldn't confuse the less technical users (the majority) with too much information. They just want to know what to do.

If this is caused by upgrading between alpha or dev versions, I don't think this is major. After all, updates aren't supported until we reach beta.

It hard to help you debug if I can't reproduce your situation. It would be interesting to know (but maybe a lot of work for you) what would happen if you rebuild your current installation from scratch, just to see if the problem comes back.

Do you work with a debugger? Maybe you can set a breakpoint at the line $incompatible_updates_exist = TRUE; and see which module is causing the problems. Alternatively, assuming that you have devel module installed, you could insert dsm(get_defined_vars()); there and see what it returns.

There is no argument why this is critical.

This is actually critical.

1. Module is installed. At the time of installation, there are some updates in the .install file
2. The module maintainer clears out the old updates and implements hook_update_last_removed()
3. When updating, we check if the schema version is less than the last removed update, and bail out if it isn't. In this case the schema version is 0, because no updates were run.

This is going to affect many, many modules being upgraded from D6 to D7.

Fortunately it's also an easy fix, untested patch for that.

This only deals with part 1 of salvis' post, which is the critical bit for me, part 2 I didn't look into yet but is more of an annoyance.

The warning got harder to see. I think that’s intended.

Let's get salvis to report on whether this fixes the issue in FA or not.

Warning in #7 is not translatable.

Not added by this patch, feel free to open a new, non-critical issue for it though.

#7 cannot be the correct fix.

The problem is probably that *on install* we set the schema version to the greatest available update function:

$versions = drupal_get_schema_versions($module);
drupal_set_installed_schema_version($module, $versions ? max($versions) : SCHEMA_INSTALLED);

This needs to be modified to account for [module]_last_removed():

$version = SCHEMA_INSTALLED;
if ($versions = drupal_get_schema_versions($module)) {
  $version = max($versions);
}
if ($last_removed = module_invoke($module, 'update_last_removed')) {
  $version = max($version, $last_removed);
}
drupal_set_installed_schema_version($module, $version);

If we do it that way, it could still leave you in a tricky position:

1. Install Drupal 7 version of a module
2. Module maintainer adds hook_update_last_removed() for D6 updates later on.
3. You still end up with schema version 0 and can't upgrade.

However, that's arguably a bug in the module, and my patch would also allow for this to happen, which is worse:

1. Install Drupal 6 version of a module
2. Don't both upgrading it ever.
3. Try to upgrade in D7 despite there having been loads of releases in between.

The snippet provided would result in max(FALSE); which PHP doesn't accept, put back the ternary, added some comments. This should be OK now.

1. Install Drupal 7 version of a module
2. Module maintainer adds hook_update_last_removed() for D6 updates later on.
3. You still end up with schema version 0 and can't upgrade.

When you install the Drupal 7 version of the module, you will not have a schema version of 0, assuming the module author shipped the D7 version with the D6 updates (which he should).

The snippet provided would result in max(FALSE); which PHP doesn't accept, put back the ternary, added some comments. This should be OK now.

I don't see how ;)

Anyway, #13 looks ok.

doh, if ($versions) {, clearly I can't read this week :(

On schema version 0 - yes it was if the D7 version shipped without, in other words a bug in the module, we don't need to allow for that case, but that was how I ended up with if !empty() in the first place, just explaining the broken line of thought that got me there...

When you install the Drupal 7 version of the module, you will not have a schema version of 0, assuming the module author shipped the D7 version with the D6 updates (which he should), or implemented [module]_update_last_removed()

Yeah the only case where this could still be broken is if you removed all the updates, didn't implement the hook, then later implemented the hook, but we can't account for that from core.

Committed #13 to HEAD. Thanks!

It sounds like we need a follow-up, non-critical documentation clarification issue (cross-linked here) for hook_update_last_removed(). salvis, would you be willing to take point on that since you know first-hand what confused you reading this for the first time?

In what way is core ignoring it? system.module declares the hook, and for core that counts for all other modules too since it's a single project.

Well the _update_7xxx() functions are from 6.x-7.x, and they'll stay in system.install for the duration of the D7 lifecycle. I'd call that one major release. However a rule of thumb is just that, there's no hard and fast rule for what gets removed, and I'd suggest the rule of thumb being given there is fairly conservative.

Displaying the results of hook_update_last_removed() is still totally broken: #834848: Warning message regarding hook_update_last_removed() is not displayed

Subscribe.

I'm looking at this issue due to a D5 -> D6 -> D7 migration I did earlier today of a simple site.

@mgifford while I was looking to solve the same issue (d5->d6->d7) one thing came up: in d5 I had once installed but never used webform module. It was not upgraded in d6 but as soon as I enabled it in d7 the message disappeared.

So just think which modules you had before which are not in your current setup or not enabled. Hope it helps.

Thanks @betarobot I think I got this addressed. However, if it comes up again I'll give that a try.

This is still broken in the release version of Drupal 7.0.

I've got a Drupal 5.23 site I'm attempting to update to Drupal 7.0. I'm staging the update on an alternate copy so I can revert to a copy of the production site and start over at any time to help test it. I'm upgrading from 5.23 to 6.20, running all updates on 6.20, then updating from there to 7.0.

As mentioned in the comments above, the Webform module appears to be at fault. Removing that module makes the error go away. However, the update system is still not giving any indication what the unmet dependencies are, or even which module is claiming it has unmet dependencies. Tracking down the errant module is quite difficult without at least an indication of which module is reporting the error. There's not even a log entry that I can find (and if there was something in the log, the error message should link to the log viewer for more details).

That's a duplicate of this issue then #834848: Warning message regarding hook_update_last_removed() is not displayed, see you over there.

I posted in the new issue but no responses yet. Would love any troubleshooting steps I can perform. This one is a showstopper when it happens.

This is still a duplicate, having two issues open for the same thing just halves the possible attention to the potential fix. I posted on the other issue though.

Some of the pending updates cannot be applied because their dependencies were not met.

Still can't get rid of this error message. (although i have managed to get rid of all the php errors related to long disabled or removed or uninstalled modules over the course of a 4.7> 5.x>6.x> 7 lifecycle.

Fixing status - the patch here was committed to Drupal 7 many years ago, so the issue can't be a duplicate. If there are still problems related to this, create a new issue and link to it from here.

wow... went looking for this as it shows on my D8 site... and found this 9 yr old, fixed ages ago post. :(