Armadilloフォーラム

mkswu実行時にversion名が省略されるのを回避したい

tkhrosm

2025年6月13日 17時13分

==========
製品型番:
Debian/ABOSバージョン:
カーネルバージョン:
3G/LTE モジュール情報 (Debianのみ):
その他:mkswuバージョン:7.6.2
==========

お世話になっております。
mkswuでswuファイルを作成する際に、descファイルに "swdesc_option version=1.0.0-dev.1" のように記載したところ、以下のように省略されました。

Warning: <image> のバージョン 1.0.0-dev.1 は 1-dev.1 に略されました。

バージョン名はX.Y.Zで管理したいのですが、こちらを回避する方法はありますでしょうか?
よろしくお願いいたします。

コメント

at_dominique.m…

2025年6月13日 17時39分

tkhrosmさん

お世話になっています、
マルティネです。

> mkswuでswuファイルを作成する際に、descファイルに "swdesc_option version=1.0.0-dev.1" のように記載したところ、以下のように省略されました。
>
>

> Warning: <image> のバージョン 1.0.0-dev.1 は 1-dev.1 に略されました。
> 

>
> バージョン名はX.Y.Zで管理したいのですが、こちらを回避する方法はありますでしょうか?

すみません、こちらはワーニングとして表示していますが、無視していただいていいと思います。

背景としては、swupdate として 1.0.0-dev.1 と 1-dev.1 は同じバージョンですが、mkswu のスクリプトでバージョンを比較している sort -V コマンドでは 1.0.0-dev.1 は 1-dev.1 より大きい扱いされます。
swupdate としては同じなので、結局どうしても同じということで最初から .0 文字列を削除するようにしましたが、メッセージはワーニングではなく info 程度でいいと思います。今度のバージョンにログを調整します。
desc ファイルのなかでは 1.0.0-dev のままで管理していただいても全く問題ありません。

ただし、/etc/sw-versions (ABOS web で表示されるバージョン等)では 1-dev.1 として表示されますのでご了承ください。

こちらの説明で大丈夫でしょうか?

(SWU内・Armadillo上でも 1.0.0 として扱うために対策は実装可能ですが、バージョンの処理はすでに複雑でこれ以上の変換処理を追加しない方がいいと判断しました)

お手数ですがよろしくお願いします。

マルティネさん
ご回答ありがとうございます。

> 背景としては、swupdate として 1.0.0-dev.1 と 1-dev.1 は同じバージョンですが、mkswu のスクリプトでバージョンを比較している sort -V コマンドでは 1.0.0-dev.1 は 1-dev.1 より大きい扱いされます。
> swupdate としては同じなので、結局どうしても同じということで最初から .0 文字列を削除するようにしましたが、メッセージはワーニングではなく info 程度でいいと思います。今度のバージョンにログを調整します。
> desc ファイルのなかでは 1.0.0-dev のままで管理していただいても全く問題ありません。
>
> ただし、/etc/sw-versions (ABOS web で表示されるバージョン等)では 1-dev.1 として表示されますのでご了承ください。
>
> こちらの説明で大丈夫でしょうか?
>
>
> (SWU内・Armadillo上でも 1.0.0 として扱うために対策は実装可能ですが、バージョンの処理はすでに複雑でこれ以上の変換処理を追加しない方がいいと判断しました)
>
> お手数ですがよろしくお願いします。

バージョン番号省略の背景について把握いたしました。
Armadillo上のアプリで自身のバージョンを判断する際に/etc/sw-versionsを参照していたのですが、その際にX.Y.Zの正規表現でチェックしていました。
これまでは確認用として0.0.1で試していたため問題無かったのですが、1.0.0にしたところその方法ではバージョンを取得できなくなってしまったというのがこちらの背景です。

1.0.0-dev.1の形式を保ったファイルがArmadillo上に存在しないのであれば、アプリ側で1-dev.1 -> 1.0.0-dev.1に補正する必要あるということでしょうか?
その場合、バージョン名が書き換えられる条件を把握しておきたいです。X.Y.Zの内、Zから順に0だった場合は削除されるルールと想定しています。例えば、以下の変換処理で問題無いでしょうか?
<想定変換処理例>
1.0.0 -> 1
1.2.0 -> 1.2
0.2.0 -> 0.2
1.0.30 -> 1.0.30 (変換無し)

お手数をおかけしますが、ご確認お願い致します。

at_dominique.m…

2025年6月13日 18時43分

tkhrosmさん

マルティネです。

> Armadillo上のアプリで自身のバージョンを判断する際に/etc/sw-versionsを参照していたのですが、その際にX.Y.Zの正規表現でチェックしていました。
> これまでは確認用として0.0.1で試していたため問題無かったのですが、1.0.0にしたところその方法ではバージョンを取得できなくなってしまったというのがこちらの背景です。

なるほど、お手数をおかけしました…

> 1.0.0-dev.1の形式を保ったファイルがArmadillo上に存在しないのであれば、アプリ側で1-dev.1 -> 1.0.0-dev.1に補正する必要あるということでしょうか?

そうですね、細かいルールもありますので必ず元のバージョンに戻れる保証はないですが、形が決まってればそういう処理は可能です。

別の案としては、情報を別のところで管理していただいた方が楽かもしれません。
特定のソフトウェアのバージョンでしたら /var/app/rollback/volumes 等にでも別のファイルとして保存すれば、こういう処理は絶対に入らないので安全に利用できます。
情報を複製する面では勿体ないですが、 /etc/sw-versions は ABOS の内部仕様だと考えていますので(予定はないですが)swupdate でバージョンの書き方が変更されればこのファイルも変わる可能性は一応ありますので、アプリケーションで利用するデータは管理できるところに保存した方がいいと思います。

> その場合、バージョン名が書き換えられる条件を把握しておきたいです。X.Y.Zの内、Zから順に0だった場合は削除されるルールと想定しています。例えば、以下の変換処理で問題無いでしょうか?
> <想定変換処理例>
> 1.0.0 -> 1
> 1.2.0 -> 1.2
> 0.2.0 -> 0.2
> 1.0.30 -> 1.0.30 (変換無し)

はい、これと不要な 0 も削除されます(例えば u-boot バージョンの 2020.04 は 2020.4 になります)が、semver 周りの処理で省かれない場合もありますので分かりにくい状態になってしまってます
参考にテスト値は test_version_normalize() にあります:
https://github.com/atmark-techno/mkswu/blob/master/tests/scripts.sh#L45
実装は normalize_version() です:
https://github.com/atmark-techno/mkswu/blob/master/mkswu#L350

よろしくお願いします。

マルティネさん

お世話になっております。

> > 1.0.0-dev.1の形式を保ったファイルがArmadillo上に存在しないのであれば、アプリ側で1-dev.1 -> 1.0.0-dev.1に補正する必要あるということでしょうか?
>
> そうですね、細かいルールもありますので必ず元のバージョンに戻れる保証はないですが、形が決まってればそういう処理は可能です。
>
> > その場合、バージョン名が書き換えられる条件を把握しておきたいです。X.Y.Zの内、Zから順に0だった場合は削除されるルールと想定しています。例えば、以下の変換処理で問題無いでしょうか?
> > <想定変換処理例>
> > 1.0.0 -> 1
> > 1.2.0 -> 1.2
> > 0.2.0 -> 0.2
> > 1.0.30 -> 1.0.30 (変換無し)
>
> はい、これと不要な 0 も削除されます(例えば u-boot バージョンの 2020.04 は 2020.4 になります)が、semver 周りの処理で省かれない場合もありますので分かりにくい状態になってしまってます
> 参考にテスト値は test_version_normalize() にあります:
> https://github.com/atmark-techno/mkswu/blob/master/tests/scripts.sh#L45
> 実装は normalize_version() です:
> https://github.com/atmark-techno/mkswu/blob/master/mkswu#L350

情報共有ありがとうございます。完全な補正を実装しようとすると複雑になってしまいますね。
こちらのバージョン仕様にのみ対応した補正でなら実装可能にはなりそうです。

> 別の案としては、情報を別のところで管理していただいた方が楽かもしれません。
> 特定のソフトウェアのバージョンでしたら /var/app/rollback/volumes 等にでも別のファイルとして保存すれば、こういう処理は絶対に入らないので安全に利用できます。
> 情報を複製する面では勿体ないですが、 /etc/sw-versions は ABOS の内部仕様だと考えていますので(予定はないですが)swupdate でバージョンの書き方が変更されればこのファイルも変わる可能性は一応ありますので、アプリケーションで利用するデータは管理できるところに保存した方がいいと思います。
>

たしかに、別ファイルとしての管理が確実ですね。
/etc/sw-versionsの変更の可能性を考慮すれば、こちらの方が適切と感じました。
一度この方法で設計を検討します。

ご対応いただきありがとうございました。