Integrity constraint violation during Aegir installation

Hello,

1. Downloaded the latest dev version of Localized Drupal distribution and l10n_update module.
2. Applied this patch.
3. Installed Localized Drupal and I had no problem.

It seems to me it works flawlessly. Thanks.

Hm, can someone explains what is this patch resolving in practice and why it is needed? The description / patch is short on any details. (Would be great to get in a short comment in the patch after that about it).

For an example, when you are trying to install Localized Drupal distribution, you get an integrity constraint violation message like this

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'l10n_client' for key 'PRIMARY' at: xxxx/install.php?profile=l10n_install&locale=nl

if you also enabled the localization client module. If you don't then the installation will work fine.
It works without any errors with this patch when I enable the l10n_client module.

Why / how is this patch solving that issue?

How does that cause integrity constraint violation? Would we not be better to resolve that problem instead of special casing for the occasion when this happens in the installer?

Related #1490664: site-install fails when installing via a custom install profile, at the least does both the suggested patches fix my site-install. By the look of it is it prob. not only related to SQLite.

It seems this patch only disables proper initialisation of l10n_update, not really what I'm looking for! I could also simply exclude l10n_update from my install profile. But it would be really nice if aegir could deliver a custom drupal install from scratch including all proper translations for most modules OOTB.

For what it's worth, this is my/our problem:

Aegir + drupal 7.14 platform with a customised install profile that includes the dutch .po file so I can install sites in dutch. It seems manually installing this setup is no problem but with aegir (which uses drush under water) a fatal sql integrity constraint is encountered.

In some cases, during installation where several modules are installed as dependencies, l10n_update attempts to write the same project to the table twice. I'm not sure why this happens, but I put drupal_write_record() in a try/catch block to avoid crashing the installation process, and it works for me.

It is not the right solution, as it only fixes the symptom, yet it might work if you cannot install or test a site due to this problem.

See enclosed patch.

Here is another version of the patch at #10. This one sets WATCHDOG_INFO instead of WATCHDOG_ERROR; this can be useful if you have a CI server like Jenkins parsing the console output, and [error] triggers a build to fail.

Don't fight symptoms, fight the cause instead. If someone can provide a simple installation profile that demonstrates the problem, I can assist in the fight by testing your patches.

Back to postponed, until we have this install profile.

Fixed it like this:

- Include l10n_update as last module in the install profile
- re-use the drush update code as an install_task

Result: a fully translated website from the get-go

I'm sure there are better ways of doing this. The result however is all modules get translated, not just the ones you enable after l10n_update gets installed.

Any patches goes against dev.

typo

Committed #11 patch, with a todo to use db_merge() instead.