- dnf module list でモジュール一覧がでてくる
# dnf module list
firmware for qemu, built by jenkins, fresh from git repos 2.4 kB/s | 2.9 kB 00:01
Fedora Modular 29 - x86_64
Name Stream Profiles Summary
ant 1.10 default [d] Java build tool
avocado latest minimal, default Framework with tools and libraries for Automated Testing
avocado stable minimal, default Framework with tools and libraries for Automated Testing
container-tools 2017.0 default Common tools and dependencies for container runtimes
container-tools 2018.0 default Common tools and dependencies for container runtimes
cri-o 1.11 default Kubernetes Container Runtime Interface for OCI-based contai
ners
cri-o 2017.0 default Kubernetes Container Runtime Interface for OCI-based contai
ners
cri-o 2018.0 default Kubernetes Container Runtime Interface for OCI-based contai
ners
django 1.6 python2_development, default [d] A high-level Python Web framework
docker 2017.0 default Module for docker runtime and docker-distribution
dwm 6.0 user, default [d] Dynamic window manager for X
dwm 6.1 [d] user, default [d] Dynamic window manager for X
dwm latest user, default [d] Dynamic window manager for X
- moduleは実際上小さなリポジトリ。ただしmoduleを有効にしないとパッケージを取得できない。
- dnf module enable dwm:6.0 のようにmodule を有効にする
- リポジトリからmoduleへweak referenceが貼られて、インストール時の解決に使われるようになるイメージ
- dnf module disable をしてもweak refがかわるだけで今はいっているパッケージに影響はない
- dnf module enable をしてもweak refがかわるだけで今はいっているパッケージと競合するとしても特に警告などはない
- dnf module remove をすると指定したmoduleに属するパッケージを削除できる。
- moduleのenable/disableがrpmパッケージ群の状態と独立しているので……
- moduleを切り替えながらいろいろやるとバージョンが混在して依存関係解決がむずかしい
- rpmの別バージョンを同時にはインストールできない制約は有効なので致命的に壊れることはない
- 実用上はmoduleのバージョン切り替えをしたい場合はremoveするしかなさそう。
悪い点: 同時にインストールできないからSoftware Collectionsより能力としては劣化してる。modularityの人はそういうときはコンテナ使えばいいと言っている。
予想されるまずいケース: rpmfindなりISV提供なりでmodularityを考慮していないrpm入れる→しばらくしたあとmoduleを使おうとする→moduleと競合する→わけがわからなくなる
