Akihiro Kuroiwa's Shop

タグ: package

  • Snap パッケージを開発して学んだこと

    fpocket を題材にした CI/CD と Snapcraft 実践録

    ここでは、私がオープンソースの分子ポケット検出ツール fpocket を snap パッケージ として公開しようと試みた経験をまとめます。
    Snapcraft の基本から GitHub Actions を用いた CI/CD、自動更新チェックの仕組み、そしてつまづいたポイントまで、私が実際に体験した内容を中心に書いています。

    snap パッケージ化に興味がある方や、CI を使った自動ビルド・公開を行いたい方の参考になれば幸いです。

    1. はじめに

    Linux ディストリビューション間で依存関係の差があると、バイナリ配布が難しくなることがあります。
    fpocket は C 言語製で比較的コンパイルしやすいのですが、一般ユーザーにとってはインストールの手順が多く、簡単とは言えません。

    そこで、クリック一つでインストールできる snap パッケージとして提供できれば便利だと考え、開発を始めました。

    しかし、snapcraft は奥が深く、パッケージング・CI/CD・Snap Store 運用など、多くの学びがありました。
    この記事では、そうした経験を整理して紹介します。

    2. Snapcraft の基礎

    まず、Snapcraft の基本を簡単におさらいします。

    ● snap の confinement

    snap にはアプリの権限レベルを示す confinement（制限モード） があり、次の 3 種類があります。

    モード 説明
    strict 最も制限が強く、標準的なモード。Snap Store で公開する場合は基本これ。
    devmode 開発用。strict に必要な許可が足りていない場合でも動くが、公開不可。
    classic 権限制限なし。伝統的ツール向け。使用には審査が必要。

    一般的な CLI ツールは strict で動かすのが基本です。また今回の fpocket-snap では、 interfaces は home のみを使用します。

    ● Snapcraft のビルド方式

    snap のビルドには複数の方法があり、それぞれ環境の隔離強度が異なります。

    ビルド方法 特徴
    Multipass core20の場合、Multipassはすべてのプラットフォームでデフォルトのプロバイダー。
    LXD core22以降では、LinuxではLXDがデフォルトプロバイダーであり、macOSおよびWindowsではMultipassがデフォルトとなる。
    –destructive-mode ホスト環境でビルド。再現性は低いが高速。

    この中で、特に注意が必要なのが --destructive-mode です。後述します。

    3. --destructive-mode とは何か

    Snapcraft には、ビルド時に --destructive-mode という特別なオプションがあります。

    snapcraft --destructive-mode

    ● 何ができるのか

    • Multipass や LXD が不要
    • つまり build container 起動不要
    • ホスト環境上で直接ビルドできる
    • CI での簡易ビルドやデバッグに便利
    • VM が起動できない環境で使える

    ● なぜ用意されているのか

    • 「動くかどうかだけ確認したい」
    • 「依存パッケージが揃っている環境で簡単に試したい」
      といった、開発者向けの簡易ビルド用途が目的です。

    ● 公開用パッケージに使ってはいけない理由

    結論として、このモードでビルドした snap を Snap Store に公開するべきではありません。

    理由は次の通りです。

    • ビルド環境の汚染が反映される可能性がある（再現性がない）
    • 必要な依存関係が “たまたま” ホストにあるために成功してしまう
    • ビルド環境とsnap baseが一致するとは限らない
    • 安全性の検証が不完全になる
    • Snapcraft 公式が推奨していない

    core22 指定なのに Ubuntu 24.04 でビルドすればエラーになるでしょう。GitHub でホストされる runner （この場合はUbuntu）がずっと同じバージョンとは限りません。

    つまり、開発や検証のためのモードであり、最終版の公開には使用しないのが正しい使い方です。

    4. fpocket-snap の構成説明

    私が構築したリポジトリは次のような構成にしています。

    fpocket-snap/
├── .github/
│   └── workflows/
│       ├── release.yml
│       └── upstream-check.yml
└── snap/
    └── snapcraft.yaml

    GitHub Actions で自動ビルド・公開し、加えて upstream の fpocket に更新がないか定期的にチェックする仕組みを入れています。

    5. snap/snapcraft.yaml の詳細解説

    Snapcraft の定義ファイルは本来リポジトリ直下に置くことが多いのですが、今回は整理のために snap/ ディレクトリに配置しました。

    ● snap/ に置く理由

    • プロジェクトルートを汚さない
    • GitHub Actions で複数の設定を扱うときに見通しが良い
    • Snapcraft 側も問題なくサポートしている

    ● 主な構成

    fpocket-snapのsnap.yamlを参照してください。

    内容としては次のポイントが重要です。

    • makefile に書かれているパス等の調査を反映
    • parts でソースコードとビルド手順を指定
    • build-packages はコンパイルに必要なパッケージ
    • stage-packages はランタイム依存
    • strict モードで動作するように設計
    • Snap Store のページ の紹介文になる情報も記載する
    項目 説明
    summary ストアの検索結果などに表示（短文）
    description 詳細ページに表示（複数行OK）
    title 見出しとして表示される（省略可）
    作成者名 snapcraft.yaml 内には不要（ストア登録時にアカウント名が自動的に「publisher」として表示）
    README.md 自動では反映されない。description部分が代わりに使われる。
    スクリーンショット 手動でSnapcraftダッシュボードからアップロード可能。
    フィールド 目的 fpocket の場合の内容
    website Snapパッケージに関する公式ページ（＝あなたがメンテナンスしているsnapラッパープロジェクト） 🔗 https://github.com/akuroiwa/fpocket-snap
    source-code ソフトウェア本体（上流プロジェクト）のソースコードURL 🔗 https://github.com/Discngine/fpocket など、fpocketの公式リポジトリ

    Snapcraft の定義は簡潔ですが、Tiny な CLI ツールには十分です。

    6. GitHub Actions のワークフロー構成

    6-1. release.yml

    この workflow は タグを切ったときに snap をビルドして Store へ公開するためのものです。

    主な流れは次のとおりです。

    1. コード checkout
    2. snapcore/action-build@v1 で snap をビルド
    3. snapcore/action-publish@v1 で Store に公開

    ● snapcraft.yaml が snap/ にある場合

    デフォルトではルートにあると認識されるため、次の指定が必要です。

    with:
  path: snap/

    これがないとビルドが失敗します。

    ● パッケージ名登録と認証トークン

    パッケージ名は事前に調べ、snap store に存在しないことを確認しなければなりません。Ubuntu One のアカウントが必要です。

    snapcraft register fpocket
snapcraft export-login --snaps fpocket --channels stable,edge snapcraft_token.json
snapcraft logout

    生成したトークンの中身（ファイル内の文字列）を GitHub Actions の secret にペーストし保存しますが、その際に yml ファイルから呼び出す環境変数名でなければなりません。

    私の場合、トークン生成時にチャンネル指定の不備が原因で公開に失敗し、再登録後に workflow を re-run して修正することがありました。使用するチャンネルが複数ある場合は必ず指定しなければなりません。

    6-2. upstream-check.yml

    fpocket 自体の更新を監視するための workflow です。

    • cron で定期実行
    • GitHub Releases を確認
    • 新しいリリースがあれば issue を自動作成
    • Issue 作成時にメール通知されるため、見逃しにくい

    fpocket の upstream に動きがあった際に素早く対応できるので便利です。

    7. GitHub Actions: Snapcraft Actions の解説

    ◎ snapcore/action-build@v1

    Snap をビルドする Action です。この アクション は自動で LXD を使います。

    ◎ snapcore/action-publish@v1

    ビルドした snap を Snap Store のチャネルに公開します。

    with:
  release: stable

    チャネルとしては stable, candidate, beta, edge が選べます。
    オプション無しでインストールできるのは stable（安定版）のみです。

    snapcore/action-build@v1 の出力は id: build を付けることで ${{ steps.build.outputs.snap }} として利用可能です。これにより、.snap の明示的なパス指定（snap/*.snap）が不要になります。

    8. 実際のトラブルと解決策（経験ベース）

    ここからは、私が実際に遭遇したトラブルです。

    ● snapcraft コマンドの変更

    snapcraft list-revisions

    は現在、

    snapcraft revisions

    にリネームされています。
    古いコマンドを使うと警告が出ます。

    snapcraft revisions fpocket #Rev.としてrevision番号を出力する
snapcraft release fpocket 1 stable #Rev.を特定した1で指定しstableに昇格する

    ● トークン無効による公開失敗

    snapcraft export-login で作成したトークンが権限不足で動作せず、
    workflow が失敗することがありました。
    再生成と再登録で解決しました。

    ● 構成順序のミス

    設定順序の問題で snapcraft が正しく読み込まれず、ビルドエラーが発生したこともあります。snapcore/action-build@v1 実行後でなければ動作しません。snapcraft: command not foundと怒られてしまいます。
    workflow ファイルの記述順は意外と重要です。

    9. まとめ

    fpocket の snap 化を通じて、多くの知見を得ました。

    • snapcraft は強力だが慣れが必要
    • strict モードで動かすための調整が大切
    • GitHub Actions での自動ビルド・公開は便利
    • --destructive-mode は開発時に便利だが、本番公開には不向き
    • upstream 更新チェックによる自動監視は役立つ

    snap パッケージの配布は、Linux ユーザーにとってインストール手順を大幅に簡略化できるメリットがあります。
    今後は multi-arch 対応や、自動テストなどを取り入れて改善していきたいと思います。

  • Pythonパッケージをソースからインストールする

    Gitリポジトリからのpythonパッケージインストール方法

    GitHubやその他のバージョン管理システム(VCS)のリポジトリから直接Pythonパッケージをインストールすることができます。これは、まだPyPIに公開されていないパッケージや、最新の開発バージョンを使用したい場合に特に便利です。

    Gitリポジトリからpythonパッケージをインストールする方法には、主に2つのアプローチがあります：リモートリポジトリから直接インストールする方法と、ローカルにクローンしたリポジトリからインストールする方法です。

    リモートリポジトリから直接インストール

    基本的な使用方法

    pip install git+https://github.com/username/repository.git

    具体的な例

    1. 公開リポジトリからのインストール:
    pip install git+https://github.com/numpy/numpy.git
    1. 特定のブランチやタグからインストール:
    pip install git+https://github.com/username/repository.git@branch-name
pip install git+https://github.com/username/repository.git@v1.0
    1. サブディレクトリにあるパッケージのインストール:
    pip install git+https://github.com/username/repository.git#subdirectory=package_dir

    プライベートリポジトリからのインストール

    プライベートリポジトリからインストールする場合、認証が必要です。

    1. HTTPSを使用する場合:
    pip install git+https://username:password@github.com/username/repository.git

    注意: パスワードをコマンドラインに直接入力することは推奨されません。代わりに、個人アクセストークンを使用することをお勧めします。

    1. SSHを使用する場合:
    pip install git+ssh://git@github.com/username/repository.git

    SSHキーの設定が必要です。

    requirements.txtでの使用

    requirements.txtファイルでGitHubリポジトリを指定することもできます:

    git+https://github.com/username/repository.git@v1.0

    ローカルにクローンしたリポジトリからインストール

    このアプローチは、リポジトリをローカルマシンにクローンし、そのディレクトリに移動してインストールする方法です。

    手順

    1. リポジトリをクローン:
    git clone https://github.com/username/repository.git
    1. クローンしたディレクトリに移動:
    cd repository
    1. パッケージをインストール:
    pip install .

    具体的な例

    git clone https://github.com/username/my-project.git
cd my-project
pip install .

    開発モードでのインストール

    パッケージを開発中で、ソースコードを編集しながらテストしたい場合は、開発モードでインストールすることができます：

    pip install -e .

    -eオプション（または--editable）を使用すると、パッケージがソースディレクトリにリンクされ、ソースコードの変更がすぐに反映されます。

    注意点

    • どちらの方法でも、リポジトリにはsetup.pyまたはpyproject.tomlファイルが含まれている必要があります。
    • ローカルにクローンする方法は、パッケージのソースコードを確認したり、修正を加えたりする場合に特に便利です。
    • 開発モードでのインストールは、自作のパッケージを開発する際に非常に有用です。
    • セキュリティ上の理由から、信頼できるソースからのみインストールしてください。
    • 依存関係の管理に注意が必要です。特に、複数のプロジェクトで作業している場合は、仮想環境の使用を検討してください。

    まとめ

    GitリポジトリからPythonパッケージをインストールする方法は、開発中のパッケージや、まだPyPIに公開されていないパッケージを使用する際に非常に便利です。リモートからの直接インストールとローカルにクローンしてからのインストールの両方の方法を理解しておくことで、様々な状況に対応できます。

    Citations:
    [1] Python のビルドとテスト
    [2] Python配布パッケージをGitHubリポジトリ経由でインストールする方法（PublicとPrivate両パターン）
    [3] setup.pyのないGitHubリポジトリからライブラリをimportする方法
    [4] GitHub のプライベートリポジトリから Python の独自パッケージをインストールしてみた
    [5] 【Python】GitHubから直接パッケージをインストールする方法
    [6] GitHub のリポジトリを requirements.txt に含める

  • Python 3.12でのパッケージング手法の変更

    Python 3.12におけるパッケージングの変更と pandas_datareader のインストール問題

    Python 3.12では、パッケージングシステムに大きな変更が加えられました。これにより、一部のライブラリのインストールに影響が出ています。特に pandas_datareader のインストール時に遭遇する可能性のあるエラーと、その解決方法について説明します。

    pandas_datareader のインストール問題

    Python 3.12で pandas_datareader をインストールしようとすると、以下のようなエラーが発生する可能性があります：

    ModuleNotFoundError: No module named 'distutils'

    このエラーは、Python 3.12で setuptools が必要になったことが原因です。setuptools は以前は distutils モジュールに依存していましたが、Python 3.12ではこのモジュールが削除されました1。

    解決方法

    この問題を解決するには、以下の手順を試してください：

    1. setuptools を最新版にアップグレードする：
    pip install --upgrade setuptools
    1. pandas_datareader をインストールする：
    pip install pandas_datareader

    Numpy のビルドシステム変更

    Python 3.12では、Numpy のようなライブラリでもビルドシステムの変更が行われています。Numpy は Python 3.12 でデフォルトのビルドシステムを meson build system に移行しました2。これにより、setuptools の使用は非推奨となり、将来的には廃止される予定です。

    pyproject.toml の推奨

    パッケージングで pyproject.toml が強く推奨されている理由の一つは、このようなビルドシステムの変更に対応するためです。pyproject.toml を使用することで、プロジェクトのビルドシステムやその依存関係を明確に指定できます。

    以下は pyproject.toml の簡単な例です：

    [build-system]
requires = ["setuptools>=61.0", "wheel"]
build-backend = "setuptools.build_meta"

[project]
name = "example_project"
version = "0.1.0"
description = "An example project"
dependencies = [
    "pandas",
    "numpy",
]

[project.scripts]
my-script = "example_project.cli:main"

    console_scripts と名前空間

    pyproject.toml の [project.scripts] セクション（または setup.py の entry_points）で指定される console_scripts は、モジュールパスとコロンで区切られた関数名を使用します。

    例えば、example_project.cli:main は example_project/cli.py ファイル内の main() 関数を指しています。

    この指定方法はクラス定義内のメソッドにも適用できます。例えば：

    class CLI:
    @staticmethod
    def main():
        print("Hello from CLI!")

    この場合、pyproject.toml では以下のように指定できます：

    [project.scripts]
my-script = "example_project.cli:CLI.main"

  • Pythonのパッケージの作成と登録

    setup.pyとpyproject.tomlの関係

    setup.pyとpyproject.tomlの役割

    setup.pyは長い間、Pythonパッケージのビルドと配布のための標準的な設定ファイルとして使用されてきました。しかし、近年ではpyproject.tomlが推奨されています。pyproject.tomlは、パッケージングツールやその他のツールの設定を一元管理するためのファイルです。

    pyproject.tomlの利点

    1. ツールの統一:
      pyproject.tomlは、ビルドシステムの依存関係やプロジェクトのメタデータを一つのファイルにまとめることができます。これにより、プロジェクトの設定が一元化され、管理が容易になります。

    2. ビルドシステムの宣言:
      [build-system]テーブルを使用して、プロジェクトのビルドに必要なツールや依存関係を明示的に宣言できます。これにより、ビルド環境の再現性が向上します。

    3. ツール間の互換性:
      pyproject.tomlは、setuptools、poetry、flitなどの異なるビルドツールと互換性があります。これにより、特定のツールに依存せずにプロジェクトを管理できます。

    setup.pyは不要か？

    新しいプロジェクトでは、pyproject.tomlを使用することが強く推奨されています。特に、ビルド中にカスタムスクリプトを実行する必要がない場合、setup.pyは最小限のスタブとしてのみ使用されるべきです。具体的には、以下のように最小限のsetup.pyを使用できます：

    # setup.py
import setuptools
setuptools.setup()

    具体的な設定例

    以下に、pyproject.tomlの具体的な設定例を示します：

    [build-system]
requires = ["setuptools", "wheel"]
build-backend = "setuptools.build_meta"

[project]
name = "your-package-name"
version = "0.1.0"
description = "A short description of your package"
authors = [
    { name = "Your Name", email = "your.email@example.com" }
]
dependencies = [
    "requests >= 2.0.0",
    "numpy >= 1.18.0"
]

[tool.black]
line-length = 88

    PyPIへのパッケージ登録手順

    1. TestPyPIでのテスト:

      • TestPyPIにアカウントを作成し、APIトークンを取得します。
      • パッケージをビルドし、TestPyPIにアップロードしてテストします。

    2. APIトークンの取得:

      • PyPI（またはTestPyPI）のアカウント設定からAPIトークンを生成します。

    3. .pypircファイルの設定:

      • ホームディレクトリに.pypircファイルを作成し、以下のように設定します：
    [distutils]
index-servers =
    pypi
    testpypi

[pypi]
username = __token__
password = <Your-PyPI-API-token>

[testpypi]
username = __token__
password = <Your-TestPyPI-API-token>
    1. パッケージのビルドとアップロード:
      • python -m buildコマンドでパッケージをビルドします。
      • python -m twine upload --repository testpypi dist/*でTestPyPIにアップロードします。
      • テストが成功したら、python -m twine upload dist/*で本番のPyPIにアップロードします。

    まとめ

    最新の情報では、pyproject.tomlが推奨されています。特に新しいプロジェクトでは、pyproject.tomlを使用することで、設定の一元管理やビルド環境の再現性が向上します。setup.pyは最小限のスタブとして使用し、主要な設定はpyproject.tomlに記述することが推奨されます。

    Citations:
    [1] Pythonで自作ライブラリを作るとき、setup.pyに代えてpyproject.tomlを使ってみませんか？
    [2] pyproject.toml を書く
    [3] Should pyproject.toml configs always be required to use poetry? #3443
    [4] Should I be using only pyproject.toml? [closed]
    [5] pyproject.toml specification

  • Pythonの仮想環境（venv）とパッケージ管理（pip）の基本

    1. 仮想環境（venv）とは

    仮想環境は、プロジェクトごとに独立したPython環境を作成するためのツールです。これにより、異なるプロジェクトで異なるバージョンのパッケージを使用することができます。

    2. 仮想環境の作成と使用

    仮想環境の作成

    # プロジェクトディレクトリに移動
cd my_project

# 仮想環境の作成
python3 -m venv venv

    仮想環境の有効化

    # Unix/macOS
source venv/bin/activate

# Windows
venv\Scripts\activate

    仮想環境の無効化

    deactivate

    3. パッケージ管理（pip）

    pipの基本

    pipはPythonのパッケージ管理ツールで、パッケージのインストール、アップグレード、アンインストールを行います。

    パッケージのインストール

    pip install package_name

    パッケージのアップグレード

    pip install --upgrade package_name

    パッケージのアンインストール

    pip uninstall package_name

    インストール済みパッケージの一覧表示

    pip list

    パッケージの詳細情報

    pip show package_name

    4. requirements.txtの使用

    requirements.txtの作成

    プロジェクトで使用しているパッケージを一覧にして、他の開発者が同じ環境を再現できるようにします。

    pip freeze > requirements.txt

    requirements.txtからパッケージをインストール

    pip install -r requirements.txt

    5. パッケージの作成と配布

    パッケージの構成

    以下では従来の方法を説明します。強く推奨されているpyproject.tomlについては1別の機会に説明します。

    パッケージを作成するためには、以下のようなディレクトリ構造が必要です：

    my_package/
├── my_package/
│   ├── __init__.py
│   └── module.py
├── setup.py
└── README.md

    setup.pyの例

    通常、ソフトウェアの開発はパッケージのビルドを前提としているファイルとパスの構成になっていますので、GitHub等で参考となるプロジェクトの書き方を手本とするのが早道です。参考になるかどうかはわかりませんが、私の管理するプロジェクトのレポジトリはこちらです。

    console_scriptsは、例えばLinuxならばシェルコマンドとして動作します。仮想環境が~/.venv3.12ならば、~/.venv3.12/bin/以下にインストールされます。コマンドとして呼び出したい関数を指定します2。

    from setuptools import setup, find_packages

setup(
    name='my_package',
    version='0.1',
    packages=find_packages(),
    install_requires=[
        'requests',
    ],
    entry_points={
        'console_scripts': [
            'my_command=my_package.module:main',
        ],
    },
)

    パッケージのビルドと配布

    Pythonパッケージユーザーガイド（Python Packaging User Guide）をまず読みましょう。以下のコマンドでは非推奨となった方法も併記します3。

    # パッケージのビルド（非推奨となった。旧式）
python setup.py sdist bdist_wheel

# 推奨
python -m build

# PyPIにアップロードするためのツールをインストール
pip install twine

# パッケージのアップロード
twine upload dist/*

    6. Gitと仮想環境の管理

    .gitignoreの設定

    仮想環境のディレクトリをGitの管理対象から除外するために、.gitignoreファイルに以下を追加します。GitHubからコピーしてくると良いでしょう4：

    venv/

    まとめ

    この記事では、Pythonの仮想環境（venv）とパッケージ管理（pip）の基本的な使用方法について説明しました。仮想環境を使用することで、プロジェクトごとに独立した環境を作成し、依存関係の管理が容易になります。また、pipを使用してパッケージのインストールや管理を行うことで、開発効率を向上させることができます。さらに、requirements.txtを使用して環境を再現可能にし、setup.pyを使用してパッケージを作成・配布する方法も紹介しました。

    1. どうすれば setup.py ベースのプロジェクトを近代化できるでしょうか？ ↩︎
    2. 9.2. Python のスコープと名前空間 ↩︎
    3. setup.py は非推奨になりましたか？ ↩︎
    4. Python.gitignore ↩︎

  • パッケージ管理

    Debian/Ubuntuのパッケージ管理

    Debian系ディストリビューション（DebianとUbuntu）では、主に以下のパッケージ管理ツールが使用されています。

    パッケージのインストールにはroot権限が必要です。以前の記事でも触れましたが、Debianの初期設定ではsu -lでrootユーザーとして実行します。以下はUbuntuでの例です。

    APT (Advanced Package Tool)

    パッケージのインストール:

    sudo apt install パッケージ名

    パッケージの削除。後者はホームディレクトリ下を除く設定ファイル等も削除する:

    sudo apt remove パッケージ名
sudo apt purge パッケージ名

    パッケージリストの更新。インストール前やアップグレード前に行う:

    sudo apt update

    システム全体のアップグレード:

    sudo apt upgrade

    パッケージの削除を伴うシステム全体のアップグレード:

    sudo apt full-upgrade

    パッケージの検索:

    apt search 正規表現

    パッケージの情報取得:

    apt show パッケージ名

    dpkg

    低レベルのパッケージ管理ツールです。

    .debファイルのインストール:

    sudo dpkg -i パッケージ名.deb

    インストールされたパッケージの一覧表示:

    dpkg -l

    パッケージ名に含まれるファイル一覧:

    dpkg -L パッケージ名
dpkg --listfiles パッケージ名

    ファイルがどのパッケージに含まれるか検索:

    dpkg -S filename-search-pattern
dpkg --search filename-search-pattern

    Snap

    Ubuntuで導入されたパッケージ管理システムです。coreで始まるものはbase snapで、各パッケージを動かすのに必要です。その番号はUbuntuリリースのバージョンを表します。

    Snapパッケージのインストール:

    sudo snap install パッケージ名

    インストールされたSnapの一覧表示:

    snap list

    Snapパッケージの更新:

    sudo snap refresh パッケージ名

    GUIツール

    1. App Center(Ubuntu):
      Show Appsから「アプリセンター」を開き、検索、インストール、削除が可能です。
    2. Synaptic Package Manager:
      より詳細な操作が可能なGUIツールです。
    sudo apt install synaptic

    でインストールできます。

    Fedoraのパッケージ管理

    Fedoraでは、主にDNF (Dandified Yum) を使用します。

    パッケージのインストール:

    sudo dnf install パッケージ名

    パッケージの削除。eraseというエイリアスは廃止された1:

    sudo dnf remove パッケージ名

    パッケージリストの更新:

    sudo dnf check-update

    システム全体のアップグレード:

    sudo dnf upgrade

    RPM (Red Hat Package Manager)

    低レベルのパッケージ管理ツールです。

    .rpmファイルのインストール:

    sudo rpm -i パッケージ名.rpm

    インストールされたパッケージの一覧表示:

    rpm -qa

    GUIツール

    Debian、FedoraなどのGNOMEを採用しているLinuxディストリビューションでは、GNOME Softwareがデフォルトのグラフィカルパッケージマネージャーとして使用されています。GNOME Softwareは、ソフトウェアのインストール、更新、削除を簡単に行えるGUIツールです。

    Ubuntuに関しては、以前はUbuntu Softwareが使用されていましたが、最新のバージョンではApp Center（アプリセンター）に変更されています。英語版では「App Center」、日本語版では「アプリセンター」と表示されます。

    Ubuntuでアプリセンターを開くには、以下の手順を行います：

    1. 画面左下のShow Apps（アプリケーションを表示）ボタンをクリックします。
    2. 検索バーに「アプリセンター」または「App Center」と入力します。
    3. 表示されたアイコンをクリックしてアプリセンターを起動します。

    アプリセンターでは、ソフトウェアの検索、インストール、更新、削除などの操作を簡単に行うことができます。

    まとめ

    これらのツールを使用することで、Debian、Ubuntu、およびFedoraでのパッケージ管理を効率的に行うことができます。GUIツールは初心者にとって使いやすい一方、コマンドラインツールはより詳細な制御と自動化が可能です。

    1. dnf(8) — Linux manual page ↩︎