pslaboが試したことの記録

はてなダイヤリーからはてなブログに引っ越してきました

この日記は現在実行中の減量記録を含む個人的なメモとして始めましたが、最近はコンピュータやガジェット、ハック、セキュリティネタのほうがメインになっております。

はてなダイヤリー時代はカテゴリ分けが適当だったのですが、これはそのうち直します。


Delphi / C++Builder 向けパッチの自己流管理方法

Delphi / C++Builder に限らず、ソフトウェア製品はかならずパッチやアップデートがリリースされますので、適切に適用することが大切ですね。

しかし、Delphi / C++Builder のパッチインストールはおせじにも簡単とはいいがたく、インストールがめんどくさいと思います。

たとえば 10.2 Tokyp Subscription Update 3 向けのパッチはこれだけあります。これらは個別のzipファイルで提供されることが多く、Delphi / C++Builder のインストールパスに手作業で展開する必要があります。(例外的に一部のパッチは実行形式で提供されることがあるようですけど。)

パッチ名 ダウンロードページ
30831_rad_studio_10.2.3_android_push_notification_patch https://cc.embarcadero.com/item/30831
30832_rad_studio_10.2.3_ems_package_wizard_patch https://cc.embarcadero.com/item/30832
30833_RAD_Studio_10.2.3_Context_Help_Patch https://cc.embarcadero.com/item/30833
30834_C++Builder_10.2.3_C++_Compiler_4k_Stack_Allocation_Patch https://cc.embarcadero.com/item/30834
30835_RAD_Studio?_10.2.3_iOS 11.3_Patch https://cc.embarcadero.com/item/30835
30836_delphi_10.2.3_rad_server_linux_apache_patch https://cc.embarcadero.com/item/30836
30837_rad_studio_10.2.3_ios_11.3_and_codeinsight_patch https://cc.embarcadero.com/item/30837
30838_rad_server_10.2.3_performance_patch https://cc.embarcadero.com/item/30838

こういう仕組みはシンプルだから嫌いではありませんが、それそれのパッチの適用状況がわかりづらいです。

そこで、こういう方法でパッチのインストール状況を管理することにしました。

RAD Studio のインストールフォルダに "HotFix" というフォルダを作って適用済みホットフィクスの情報を記録しておく

ツール側にパッチの適用状況を管理する仕組みがないなら、どうにかしよう、ということで、それを管理するためのフォルダを作成します。

ここには、以下のルールでファイルをパッチ単位で作っておきます。

  1. ファイル名は、パッチの番号および名前にしておく。拡張子は txt にする。
  2. ファイルの内容は、パッチが公開されているページのURLにする。

このようにしておくだけで、パッチのインストール状況が一目でわかりますし、そのパッチを他の機材に適用したい場合には、そのファイルをひらけばURLがわかるので内容の確認やダウンロードも簡単です。

どうせなら、パッチをひとまとめにしたアーカイブを作ってしまおう

とはいいつつも、複数の作業マシンを使い分けている場合は、それらに同一のパッチを入れる作業は案外めんどくさい。

また、環境をゼロから作り直す場合も同様にめんどくさい。

そこで、前述の構成をとりつつ、複数のパッチをマージしたアーカイブを作ってしまえば、すべてのパッチを一括で導入できますし、何を適用しているかもわかります。

では、そのアーカイブはどんな形式で作るのがよいのか?

普通に考えれば zip 形式一択なのですけど、zip 形式は圧縮率がさほど高くないという印象があります。そこで、複数の圧縮フォーマットでファイルサイズがどれくらい変わるかを比較してみました。なお、作業の都合上、これは macOS 上で実施しております。また、処理時間は1回だけ実行した時の実測値なので処理時間の絶対値を見るのではなく、相対的に速い、遅いという観点での比較にご利用いただけます。

アーカイブ ファイルサイズ 作成方法 処理時間
R10.2.3.30831-30838.tar 1583243776 tar cvf R10.2.3.30831-30838.tar R10.2.3.30831-30838 3秒
R10.2.3.30831-30838.zip 907663024 zip -r R10.2.3.30831-30838.zip R10.2.3.30831-30838 2分45秒
R10.2.3.30831-30838.tar.gz 907840100 cat R10.2.3.30831-30838.tar | gzip -c -9 > R10.2.3.30831-30838.tar.gz 2分35秒
R10.2.3.30831-30838.tar.bz2 874491124 cat R10.2.3.30831-30838.tar | bzip2 -c -9 > R10.2.3.30831-30838.tar.bz2 2分49秒
R10.2.3.30831-30838.tar.xz 598725872 cat R10.2.3.30831-30838.tar | xz -c -9 > R10.2.3.30831-30838.tar.xz 15分32秒

*上記の処理で cat を pv (pipe viewer) に置き換えて実行すると、処理状況が可視化され、実行終了予測時間も表示されますので、私が実際に作業するときには cat ではなく pv を使います。

こうやって比べてみると、zipとgzipはファイルサイズに極端な差はありませんが、bzip2はそれよりも小さく、xzはさらに小さいことがよくわかります。圧縮のためにそれなりに時間はかかりますが、xz が取り扱えるなら基本的には xz 一択で良いと思います。

ちなみに、この xz のアーカイブを展開するためにかかる時間は、約10秒でした。圧縮には時間がかかるけれど、展開で10秒なら全く問題ないレベルです。

では、xz は Windows でどうやって扱えるか?

GUI 指向の方は 7-zip を入れておけば扱えるようですが、私は Windows 向けのGUIツールでアーカイブを扱うことを基本的にしないので、使い勝手はよく知りません。

CUI 操作に不都合がない方は、Windows Subsystem for Linux をセットアップしておけば、普通に xz や tar コマンドで扱えます。

ちなみに、Windows 側の特定のフォルダで bash で作業するのに cd コマンドで移動、とかする必要はありません。エクスプローラでそのフォルダを開いた状態で、アドレスバーから "bash" と入力するだけでよいのです。