[Obm] upgrade 2.4.1.1 -> 2.4.2.0

[Patrick BOSSARD]

Bonjour,

Je viens de faire un yum update pour passer a la derniere revision d'OBM

J'ai 2 remarques :

  * Lors de l'update du module perl-ObmSatellite je récupère l'erreur suivante :
>       Updating   : perl-ObmSatellite-2.4.2.0-1.noarch 7/42
>     Non-fatal POSTIN scriptlet failure in rpm package perl-ObmSatellite-2.4.2.0-1.noarch
>     Can't locate XML/SAX.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .).
>     BEGIN failed--compilation aborted.
>     warning: %post(perl-ObmSatellite-2.4.2.0-1.noarch) scriptlet failed, exit status 2
    Pourtant j'ai bien la version perl-XML-SAX-Base-1.04-1.el6.rf.noarch du module.
    Que faire pour regler le pb ?

  * Lors de l'upgrade BDD, j'ai un message m'invitant a passer les scripts de BDD
>       Updating   : obm-PostgreSQL-2.4.2.0-1.noarch 16/42
>     Finish upgrade Database, check /usr/share/obm/script upgrade script
    Etant deja e 2.4.1, j'aurais tendance a n'appliquer que les patch 2.4.2.. mais j'ai fait un diff par aquis de conscience...
    et la, il se trouve qu'il y a qques différences entre des .sql concernant des patchs vers la 2.4.1 :
>     [root at vagendabackend-test updates]# diff update-2.4.0-2.4.1~alpha9+git.pgsql.php DIFF/update-2.4.0-2.4.1~alpha9+git.pgsql.php
>     40,42d39
>     <
>     <      $con->query('DELETE FROM opush_event_mapping WHERE id NOT IN (SELECT MAX(id) FROM opush_event_mapping GROUP BY device_id, event_ext_id)');
>     <
>     [root at vagendabackend-test updates]# diff update-2.4.1.1~alpha1.pgsql.sql DIFF/update-2.4.1.1~alpha1.pgsql.sql
>     [root at vagendabackend-test updates]# diff update-2.4.1~alpha10+git.pgsql.sql DIFF/update-2.4.1~alpha10+git.pgsql.sql
>     [root at vagendabackend-test updates]# diff update-2.4.1~alpha6.pgsql.sql DIFF/update-2.4.1~alpha6.pgsql.sql
>     [root at vagendabackend-test updates]# diff update-2.4.1~beta1.pgsql.sql DIFF/update-2.4.1~beta1.pgsql.sql
>     8c8
>     <  DELETE FROM DeletedEvent WHERE deletedevent_id NOT IN (SELECT MAX(deletedevent_id) FROM DeletedEvent GROUP BY deletedevent_event_id, deletedevent_user_id);
>     ---
>     >     DELETE FROM DeletedEvent WHERE deletedevent_id NOT IN (SELECT MAX(deletedevent_id) FROM DeletedEvent GROUP BY deletedevent_event_id, deletedevent_user_id);
>     10,15c10
>     <  CREATE TABLE Tmp_DeletedEvent AS SELECT DISTINCT * FROM DeletedEvent;
>     <  DROP TABLE DeletedEvent;
>     <  ALTER TABLE Tmp_DeletedEvent RENAME TO DeletedEvent;
>     <
>     <
>     <  ALTER TABLE DeletedEvent ADD CONSTRAINT deletedevent_uniquekey UNIQUE (deletedevent_event_id, deletedevent_user_id);
>     ---
>     >     ALTER TABLE DeletedEvent ADD CONSTRAINT deletedevent_uniquekey UNIQUE (deletedevent_event_id, deletedevent_user_id);
>     [root at vagendabackend-test updates]# diff update-2.4.1~beta2.pgsql.sql DIFF/update-2.4.1~beta2.pgsql.sql
>     diff: DIFF/update-2.4.1~beta2.pgsql.sql: Aucun fichier ou dossier de ce type
>     [root at vagendabackend-test updates]# diff update-2.4.1~beta3.pgsql.sql DIFF/update-2.4.1~beta3.pgsql.sql
>     [root at vagendabackend-test updates]# diff update-2.4.2.0~0.alpha2.pgsql.sql DIFF/update-2.4.2.0~0.alpha2.pgsql.sql
>     diff: DIFF/update-2.4.2.0~0.alpha2.pgsql.sql: Aucun fichier ou dossier de ce type
>     [root at vagendabackend-test updates]# diff update-2.4.2.0~0.beta3.pgsql.sql DIFF/update-2.4.2.0~0.beta3.pgsql.sql
>     diff: DIFF/update-2.4.2.0~0.beta3.pgsql.sql: Aucun fichier ou dossier de ce type
>     [root at vagendabackend-test updates]# diff update-2.4.2.0~0.beta4.pgsql.sql DIFF/update-2.4.2.0~0.beta4.pgsql.sql
>     diff: DIFF/update-2.4.2.0~0.beta4.pgsql.sql: Aucun fichier ou dossier de ce type
>     [root at vagendabackend-test updates]#
>     [root at vagendabackend-test updates]#
>     [root at vagendabackend-test updates]#
    Le process d'upgrade manque de clareté...
    Est ce que j'y prend mal ?, Y a il un script a passer qui saurait gérer ca de façon automatique ? (les patchsets a appliquer en fonction de ma base) ?
    Faut il que je lance les .sql manuellement, dans ce cas, j'imagine qu'il faut que je re-applique egalement certains patchs (ceux qui sont différents pour ma version 2.4.1.1 ?)


Merci à tous,

Cordialement,

Patrick.

-- 
Patrick BOSSARD - PDG/IMN/IDM/RIC
IFREMER centre de Brest
BP 70 29280 Plouzane FRANCE
Tel  : 02 98 22 44 09 - Fax: 02 98 22 45 46
Email: Patrick.Bossard at ifremer.fr

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.obm.org/pipermail/obm/attachments/20130214/782311ac/attachment.htm