I'm adding a platform to Aegir, there are no errors in the verify logs, but the install profile doesn't show up in packages/install profile tab nor in the add site form.
When I see the verify logs for the platform, it says "Found install profile xxx" for the platform, but when I look at the hosting_package table, it was added as a module.
I have a module in other platform with the same name as this platform (module name in one platform == install profile name in other), and this modue is not in hosting_package as I think it should be.
PS: Version number may be wrong, can't find it in aegir distribution.
Comment | File | Size | Author |
---|---|---|---|
#9 | hosting-fix_overwritten_packages-1263264-9.patch | 1.14 KB | ergonlogic |
Comments
Comment #1
omega8cc CreditAttribution: omega8cc commentedThis is how Drupal (single namespace) works. We can't do anything to 'fix' this. You need to use unique names and module name should never match install profile or theme name - server wide, as Aegir keeps all packages records in the same tables for all platforms.
Comment #2
recidive CreditAttribution: recidive commentedToo bad, I'll have to rename my new install profile to avoid conflict with a legacy platform module.
I still think this is a very bad Aegir limitation, or a bug, as the Drupal single namespace is not an excuse to have this server wide limitation. Drupal doesn't have this server wide, but codebase wide.
Also, there's no primary key in the package_type/short_name, this looks to me a limitation easily to be fixed, it doesn't make sense to me having shared packages across all platforms, but instead it seems more natural having it by platform.
Comment #3
omega8cc CreditAttribution: omega8cc commentedIt is not an Aegir bug, it is a Drupal limitation.
Having separate packages records per platform could be a huge overhead, plus it will still not help you when you are migrating the site from platform A with 'anything' as module/theme name to platform B with 'anything' as an install profile name.
Comment #4
recidive CreditAttribution: recidive commentedOk, I understand.
Is that documented somewhere? It needs to be documented as a limitation, that you shouldn't have install profile/module/theme, etc with the same name across all platforms as this can be very confusing.
Comment #5
recidive CreditAttribution: recidive commentedI don't agree this is a Drupal limitation as people would expect different platforms to act independently.
Comment #6
omega8cc CreditAttribution: omega8cc commentedI don't think it is our task to document all standard Drupal behaviors, however feel free to add this to our docs at http://community.aegirproject.org/notebook
And yes, it is a Drupal limitation, and not an Aegir fault or anything we could fix.
[EDIT] Oh, it is already in our FAQ: http://community.aegirproject.org/faq#namespace
Comment #7
recidive CreditAttribution: recidive commentedLike I said in IRC, I wonder if it'd be possible to support same names/different package type/different platform, as same names/same package type/different platform it already supports.
Comment #8
ergonlogicI believe this is a limitation of hosting_get_package(), actually, which only takes the packages short_name as an argument. As a result, in hosting_package_sync(), it will think it's updating an existing package, rather than creating a new one. I think we can fix this by passing package_type as a second parameter to hosting_get_package().
Comment #9
ergonlogicSomething like this should fix it. Defaulting to 'profile' just avoids having to change the only other place hosting_get_package() gets called.
Comment #10
ergonlogicThis is a bug.
Comment #11
anarcat CreditAttribution: anarcat commentedwhy do we have a default type? shouldn't this just be a mandatory argument?
i see that hosting_get_package() is also called from hosting_get_default_profile(), but if that's why, it's that function that should be changed to specify the 'profile' type.
this is an API change that should be documented as such (upgrade/path and relnotes).
Comment #12
ergonlogicYep, hosting_get_default_profile() only ever calls hosting_get_package() for a profile, hence the default $type of 'profile'. I've made it mandatory, and fixed hosting_get_default_profile().
Fixed in 5ffb399.