Posted by anarcat on October 14, 2009 at 10:52pm
Jump to:
| Project: | Hosting |
| Version: | 6.x-0.4-alpha2 |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | anarcat |
| Status: | closed (fixed) |
Issue Summary
Here's my situation: I have a site (let's call it example.com) which installed the shiny new dev version of Zen in their sites/example.com/themes. So the site verifies right and is seen as having Zen 2.x. But the target platform has (rightfully) Zen 1.0. The migrate refuses to run because it thinks it would be a downgrade, which is actually false since the theme is in the sites/example.com directory.
Migrate should consider whether the module/theme is in the sites/example.com directory before refusing to upgrade.
Note that this is different than #595294: Migrate package comparison assumes 6.x-1.x-dev is older than 6.x-1.0 , which concerns only releases on the same branch.
Comments
#1
a shorter and more appropriate name. there's also the issue that modules in sites/example.com are marked as missing if they are not in site/all, which is not quite true: they will be migrated along...
#2
I guess we'll need verify to check if the package is in sites/all or in the site directory and add a flag in the database to carry that information... unless we guess based on the module path?
#3
we could just do the check up to the profile level, and not on the site level. and just assume the modules in sites/all will move along
keep in mind you will not be upgrading these modules at all, ever through the aegir interface.
#4
subscribing
#5
I'm working on a patch to ignore site-specific modules and themes in sites/example.com/ in the discovery code. We are not doing anything with those anyways and are generally conceptually ignored by aegir.
#6
fixed pushed in git: http://git.aegirproject.org/?p=provision.git;a=commitdiff;h=9e4cedcdab43...
adrian, review?
#7
Automatically closed -- issue fixed for 2 weeks with no activity.