[sympa-fr] Problème upgrade sympa 5.3.3 vers 6.1.19

[Hadrien Pithoud <adresse@cachée>]

Bonjour à tous,
Je rencontre un problème lors de la mise à jour d'une plateforme Sympa de la 
version 5.3.3 vers 6.1.19.
Sur un Ubuntu server LTS lors de l'execution du script pour réaliser la monté 
de version je recontre l'erreur suivante : 

sympa[17787]: err Upgrade::upgrade() Unable to execute SQL statement "UPDATE 
subscriber_table SET robot_subscriber='fed92.mup.fr' WHERE 
(list_subscriber='diffusion')" : Duplicate entry 
'adresse@cachée' for key 

Aprés investigation je me suis aperçu que ce sont les clefs primaires 
définies sur les tables suivantes : subscriber_table et admin_table qui 
posent problème.

Le seul moyen que j'ai trouvé pour dérouler l'upgrade sans erreur est dans un 
premier temps de supprimer les clefs primaires sur la base de donnée MySQL.
Pour cela  dans le script Upgrade.pm dans la déclaration my %primary 
correspondant à l'application des clefs primaires (ligne 1035 et 1036) de 
commenter les deux lignes suivantes :
#                  'subscriber_table' => 
['robot_subscriber','list_subscriber','user_subscriber'],
#                  'admin_table' => 
['robot_admin','list_admin','role_admin','user_admin'],
Puis de relancer le script d'upgrade.

Avec ces actions, le script d'upgrade se déroule sans aucun soucis. Je ne 
peux malheureusement remettre en place les clefs primaires, erreur sur la 
présence d'entrées similaires dans la base par exemple :

    5. row *******************
    bounce_address_subscriber: NULL
    bounce_score_subscriber: NULL
    bounce_subscriber: NULL
    comment_subscriber: Mazziottii Jean-Pierre
    date_subscriber: 2012-11-22 18:18:49
    include_sources_subscriber: NULL
    included_subscriber: 0
    list_subscriber: discussion-adherents-ardeche-drome
    reception_subscriber: mail
    robot_subscriber: fed26.mup.fr
    subscribed_subscriber: 1
    topics_subscriber: NULL
    update_subscriber: 2012-11-22 18:18:49
    user_subscriber: adresse@cachée
    visibility_subscriber: noconceal
    custom_attribute_subscriber: NULL
    suspend_end_date_subscriber: NULL
    suspend_start_date_subscriber: NULL
    suspend_subscriber: NULL
    6. row *******************
    bounce_address_subscriber: NULL
    bounce_score_subscriber: NULL
    bounce_subscriber: NULL
    comment_subscriber: NULL
    date_subscriber: 2011-01-22 16:38:56
    include_sources_subscriber: NULL
    included_subscriber: 0
    list_subscriber: info-adherents
    reception_subscriber: html
    robot_subscriber: liste.mup.fr
    subscribed_subscriber: 1
    topics_subscriber: NULL
    update_subscriber: 2011-01-22 16:38:56
    user_subscriber: adresse@cachée
    visibility_subscriber: noconceal
    custom_attribute_subscriber: NULL
    suspend_end_date_subscriber: NULL
    suspend_start_date_subscriber: NULL
    suspend_subscriber: NULL

Je recontre une erreur sur la redondance du champ user_subscriber. (cela est 
aussi valable pour chaque champs en tant que clef primaire sur les 2 tables 
citées ci dessus)

J'ai donc deux questions :
La suppression de ces clefs primaires peut-elles avoir un impact sur le sympa 
en prodution par la suite ? Quelles sont vos recommendations à ce sujet ?
Peut-on intervenir en amont de la migration afin d'éviter cette erreur ?

Merci d'avance.

Cordialement
-- 
Hadrien Pithoud 
adresse@cachée