Weird requirements problem when trying to run update.php:

Unresolved dependency	System (Version >=7.12 required)
Administration menu requires this module and version. Currently using System version 7.10+82-dev
Error
Unresolved dependency	System (Version >=7.12 required)
Administration menu Toolbar style requires this module and version. Currently using System version 7.10+82-dev
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

sun’s picture

Category: bug » support

That's expected. :)

The current 7.x-3.x-dev depends on an API addition in Drupal core. But Drupal core has no new release yet.

As there might be a Drupal core security release in between, the new version could be 7.12, or 7.11 if not. We need to wait for the next core release.

But in other news, I'm glad to hear/see that the version-specific module dependency system in core actually works as intended. This saved you from seeing a fatal PHP error down the line.

Keeping this issue open until the next core version is clear.

klonos’s picture

Title: Requirements problem » Requirements problem (Unresolved dependency, System Version >=7.12 required)

Confirming this with latest D7 core dev.

@sun: Hey Daniel, care to point to the issue with this latest API change? Is there a patch we can apply to get this fixed w/o having to wait for the next core release?

klonos’s picture

...btw, you might want to update the project's page regarding this new requirement of the 3.x branch.

Macronomicus’s picture

dang... so this means we're back to 7.x-3.0-rc1 which is a year old & buggy.
lol.. too bad I just updated this module, I must have a backup of a more recent 3.x-dev somewhere around here, but others wont be so lucky I'm guessing. A warning would be good on the module page.

sun’s picture

Well, if it helps anyone, we could change the requirement to require Drupal core 7.x-dev (that is, >7.10) for the time being.

That will, however, have a good chance of leading to errors down the line, in case there will be a security release (I don't know whether there will be one), because core security releases only contain the security fixes, but no other changes. Thus, your system might have the requirements (core 7.11), but 7.11 won't contain the core API addition, so...

Again, we can do that. Just want to point out the possible pitfall.

klonos’s picture

...no need for any of that trouble. I *always* keep backed up 2 or 3 previous dev versions of every module I use for cases exactly like this.

How about my question in #2? Does anybody know the issue with that API change?

sun’s picture

Apparently, I don't even know how severe the error is going to be. Is anyone of you able to comment out the dependency in admin_menu.info and then test what exactly blows up? :)

(I suspect you'll see a wonky first menu link, or perhaps even full-blown link tree, in the menu, instead of the intended "Add content" link.)

sun’s picture

Status: Active » Fixed
FileSize
403 bytes

Actually, I'm relatively sure that this will only cause some menu link garbage at max. Thus, committed attached patch.

Developers using and updating dev releases should update everything to latest dev releases anyway.

MrPhilbert’s picture

"dependencies[] = system (>7.10)" does not allow module to be installed on D7.10. Only versions greater than that. I believe what you intended was "dependencies[] = system (>=7.10)" .

sun’s picture

Nope. If you intend to install and run the admin_menu 7.x-3.x-dev snapshot, then you should also have the latest Drupal core 7.x-dev (>7.10) snapshot.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

WorldFallz’s picture

Status: Closed (fixed) » Active

Seems something's up. I just created a fresh core 7.x-dev site and downloaded a fresh admin_menu-7.x-3.x-dev and I'm getting "Requires: System (>7.10) (incompatible with version 7.x-dev)" on the modules page.

I suspect it has something to do with the fact that admin/reports/status reports the drupal core version as "7.23-dev" but admin/reports/updates reports it as "Drupal core 7.x-dev (2013-Jun-23)". Core was downloaded via "drush dl drupal-7.x-dev".

poking around to see what i can figure out...

yettyn’s picture

Just hit me too, something changed in core triggering this. Before update I had
Drupal core 7.22+64-dev (2013-Jun-21)
and after
Drupal core 7.x-dev (2013-Jun-24)

I don't know why but system.info changed from

; Information added by drupal.org packaging script on 2013-06-21
version = "7.22+64-dev"
project = "drupal"
datestamp = "1371777205"

to

; Information added by drupal.org packaging script on 2013-06-24
version = "7.x-dev"
core = "7.x"
project = "drupal"
datestamp = "1372035215"

Either is this a regression or the way to check dependency somehow must have changed between the 2 dev versions.

yettyn’s picture

I have been through all changes between my last good version (June 21) and latest dev release, and there is no change in code that would cause this, except that the build script sets
version = "7.x-dev
where it previously set
version = "7.22+64-dev

So not sure if this is a one time f*ck-up or a sloppy unintentional change, and I cannot see any other architectural structure change going on, so it's a bug but where to report it, at core? as it's not an admin_menu bug as far as I can see.

yettyn’s picture

Workaround
in /modules/system/system.info
change

; Information added by drupal.org packaging script on 2013-06-24
version = "7.x-dev"

to

; Information added by drupal.org packaging script on 2013-06-24
version = "7.23-dev"

That will allow update.php to run, but not this is only a workaround until a proper fix. It's possibly the packaging script just had a temporary hickup, but question is also if the dependency shouldn't be checked against the VERSION constant and not the version variable - but I honestly don't know.

yettyn’s picture

Status: Active » Fixed

Apperently someone slipped with a tangent running the packaging script as ll back to normal now with latest dev version (Jun-27) of core.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.