プロジェクト

全般

プロフィール

OpenRTM-aist-Python »

OpenRTM-aist Python 1.1.0-RELEASEのWindows用インストーラの動作確認項目

１．インストール先の確認

  • インストーラ
    • OpenRTM-aist-Python_1.1.0-RELEASE_x86.msi
    • OpenRTM-aist-Python_1.1.0-RELEASE_x86_64.msi
  • インストール先のディレクトリ確認
    • x86用インストーラ利用（Pythonインストール先がC:\Python27の場合）
      • C:\Program Files (x86)\OpenRTM-aist\1.1
      • C:\Program Files (x86)\OpenRTM-aist\1.1\bin\jre
      • C:\Program Files (x86)\OpenRTM-aist\1.1\examples\Python
      • C:\Program Files (x86)\OpenRTM-aist\1.1\utils\RTSystemEditor
      • C:\Python27\Lib\site-packages\OpenRTM_aist
    • x86_64用インストーラ利用（Pythonインストール先がC:\Python27_x64の場合）
      • C:\Program Files\OpenRTM-aist\1.1
      • C:\Program Files\OpenRTM-aist\1.1\bin\jre
      • C:\Program Files\OpenRTM-aist\1.1\examples\Python
      • C:\Program Files\OpenRTM-aist\1.1\utils\RTSystemEditor
      • C:\Python27_x64\Lib\site-packages\OpenRTM_aist

２．スタートメニューの確認

  • RTSystemEditorRCPはC++, Python, Java の各インストーラと依存関係があるので、独立したToolsのパスに含めている
  • ネームサービス起動もRTSystemEditorRCPと同じパスに置いている

以上のことから、メニューのパスは以下となっている

OpenRTM-aist 1.1 -> Python -> Components -> Examples
OpenRTM-aist 1.1 -> Python -> Documents
OpenRTM-aist 1.1 -> Python -> Tools
OpenRTM-aist 1.1 -> Tools -> RTSystemEditorRCP
OpenRTM-aist 1.1 -> Tools -> Start Python Naming Service

３．スタートメニューからサンプルコンポーネントを起動できることの確認

  • 32/64bitそれぞれの環境で確認する
    • ConsoleIn/ConsoleOutの接続動作を確認する
      ・Start Python Naming Service
・RTSystemEditorRCP
・ConsoleIn.py
・ConsoleOut.py
  • C++, Python, Javaの組合せ動作確認
    • 2015/01/15の作業報告より
      ■32bit用使用インストーラ
・OpenRTM-aist-C++_1.1.1-RELEASE_x86_vc10.msi
・OpenRTM-aist-Python_1.1.0-RELEASE_x86.msi
・OpenRTM-aist-Java_1.1.0-RELEASE_x86.msi

・上記３つ全てインストールする

・サンプルコンポーネント接続動作確認　OK!
　・Start C++ Naming Service
　・RTSystemEditorRCP
　・ConsoleIn.bat (Java版）
　・ConsoleOut.py (Python版)
    • 2015/01/22の作業報告より
      ■C++, Python, Javaの各64bit版msiの組合せ動作確認
・OpenRTM-aist-C++_1.1.1-RELEASE_x86_64_vc10.msi
・OpenRTM-aist-Python_1.1.0-RELEASE_x86_64.msi
・OpenRTM-aist-Java_1.1.0-RELEASE_x86_64.msi

・上記３つ全てインストールする

・サンプルコンポーネント接続動作確認　OK!
　・Start C++ Naming Service
　・RTSystemEditorRCP
　・ConsoleIn.bat (Java版）
　・ConsoleOut.py (Python版)

４．OpenRTM-aist C++, Python, Java の各インストーラ組合せ動作確認

  • RTSystemEditorRCP と JRE（OpenJDK7のWindows版）は各言語インストーラと依存関係にある
  • OpenRTM-aist のどの言語版もインストールされていない環境でPython版インストーラmsiを実行すれば、RTSystemEditorRCPとJREはインストールされる
  • この環境へJava版をインストールし、その後Python版をアンインストールしてもRTSystemEditorRCPとJREは削除されず残る
  • Java版をアンインストールする時にRTSystemEditorRCPとJREも一緒に削除されるという動きになる
  • C++版インストーラのみ、インストールオプションでRTSystemEditorRCPとJREを選択できる

この動作の確認結果は、C++版の「1.1.0-RELEASEのWindows用インストーラの動作確認項目 」のチケットに添付している以下を参照
OpenRTM-aistの３言語インストーラの組合せ動作確認結果_20150415.pdf.pdf

５．アップグレード動作の確認

  • 現在のバージョンではアップグレードできない
    • 2015/01/08の作業報告より
    • 操作：Python 1.1.0-RC1がインストールされている環境へ、Python 1.1.0-RELEASEをインストールする
    • 結果
  • アップグレード実現のため試したこと
    • 2015/01/14の作業報告より
    • Python版の場合、1.1.0-RC1から1.1.0-RELEASEへのアップグレードなので、バージョン番号は同じ1.1.0である。
      これが関係しているかもしれないと考え、新バージョンを試しに1.1.1としてみたが共存してしまったと作業メモにある。
    • C++版のマージモジュールを組合せてmsiを生成しているのに対し、Pyhton（Javaもそうだが）は１つのwxsファイルで
      全てを定義している点に違いがありそうな感触だった
    • 以下、試したコード
      　・コードはC++と同様に定義
    <Property Id="NEWERVERSIONDETECTED" Secure="yes" />
    <MajorUpgrade AllowDowngrades="yes" Schedule="afterInstallValidate" />
    <Upgrade Id="{% Product.UpgradeCode %}">
      <UpgradeVersion OnlyDetect="yes" 
                      Minimum="{% Product.Version %}" 
                      Property="NEWERVERSIONDETECTED" 
                      IncludeMinimum="yes" /> 
      ※既存のUpgradeVersionエレメントは全てコメントアウトして動かす

　・確認したこと
　　・Product.Versionは、OpenRTM-aist-Python.wxs.yaml.inで定義
　　・Product.Versionを1.1.1で試したが、新旧バージョンが共存する
　　　　→コントロールパネルで新バージョンは1.1.1となっている
　　・MajorUpgradeエレメントはバージョン番号で判断している
　　・MajorUpgradeのAllowSameVersionUpgrades属性をyesで試す
　　　　→・C++版の設定は、デフォルトの no
　　　　　・この時、Product.Versionを1.1.0.1としてみた
　　　　　・だが、ドキュメントを読むと、MSIはこのバージョン番号の最初の３つの数字しか判断していないとのこと。
　　　　　・今回のように新旧のバージョン番号が1.1.0で同じ場合はMajorUpgradeは使えないっぽい

http://wixtoolset.org/documentation/manual/v3/xsd/wix/majorupgrade.html
AllowSameVersionUpgradesの説明：
Note that because MSI ignores the fourth product version field, 
setting this attribute to yes also allows downgrades when the first three product version fields are identical. 
For example, product version 1.0.0.1 will "upgrade" 1.0.0.2998 because they're seen as the same version (1.0.0). 
That could reintroduce serious bugs so the safest choice is to change the first three version fields and 
omit this attribute to get the default of no.
    • 2015/01/16の作業報告より
    • アップグレード動作の確認は何度か行ってますので、整理します。
      • C++版は 1.1.0 -> 1.1.1 へのアップグレードが可能。1.1.1インストール時に自動で1.1.0を削除します。
        実現しているのがMajorUpgradeエレメント。
      • Python/Java版はMajorUpgradeを記述しても新旧バージョンが共存する。
      • MajorUpgradeは、UpgradeCodeのGUIDが同じ場合、ProductのVersionで判断する
    • 14日に報告したテストは、1.1.0-RELEASE版のProductで定義しているバージョンを1.1.1に書き換え、1.1.0-RC1 -> 1.1.0-RELEASE と実行
      したが、共存してしまった。
    • 今日の確認は、1.1.0-RELEASEのソースでmsi２つを作成。
      一方をProductのバージョンを1.1.1に書き換えて生成する。これで、1.1.0->1.1.1の順序で実行したが、共存した。
    • このテストのために、昨日テストしたソースへ以下の変更を行った。C++版で動作しているコードを追加
      -----　追加　ここから
    <Property Id="NEWERVERSIONDETECTED" Secure="yes" />
    <MajorUpgrade AllowDowngrades="yes" Schedule="afterInstallValidate" />
    <Upgrade Id="{% Product.UpgradeCode %}">
      <UpgradeVersion OnlyDetect="yes" 
                      Minimum="{% Product.Version %}" 
                      Property="NEWERVERSIONDETECTED" 
                      IncludeMinimum="yes" /> 
-----　追加　ここまで
-----　下記コメントアウト
    <Upgrade Id="{% Product.UpgradeCode %}">
      <UpgradeVersion OnlyDetect="yes" 
                      Minimum="1.0.0" 
                      Maximum="1.1.0" 
                      Property="NEWERVERSIONDETECTED" 
                      IncludeMinimum="no" /> 
      <UpgradeVersion OnlyDetect="no" 
                      Minimum="1.0.0" 
                      Maximum="1.1.0.1" 
                      Property="OLDERVERSIONBEINGUPGRADED" 
                      IncludeMaximum="no" /> 
      <UpgradeVersion OnlyDetect='no' Property='PREVIOUSFOUND'
                      Minimum='1.0.0' IncludeMinimum='yes'
                      Maximum='1.1.0' IncludeMaximum='no' />
-----
    • Python/Java版はwxs.inの定義が長いし、RemoveFile, RemoveFolderも含んでいるので、何が影響しているのか絞りづらい。
      マージモジュールにしたら最後のmsi生成時にMajorUpgradeを定義すればいいので、うまく行きそうな気がしています。全く試していないので、勘レベルですが。