🔎 
  
Live システムマニュアル

インストールするパッケージの独自化

インストールするパッケージの独自化

恐らく Live システムの最も基本的な独自化はイメージに収録するパッケージの選択でしょう。この章では live-build でのパッケージのインストールの独自化のためのビルド時の様々なオプションを見ていきます。イメージへのインストールに利用可能なパッケージに関して最も影響が大きい選択はディストリビューションとアーカイブ領域です。まともなダウンロード速度を確保するため、近いディストリビューションミラーを選択してください。backports や experimental あるいは独自のパッケージのある自身専用のリポジトリを追加することもできます。また、ファイルを直接パッケージとして収録することもできます。特定のデスクトップや言語のパッケージ等、多数の関連パッケージを同時にインストールするメタパッケージを含め、パッケージ一覧は定義できます。最後に、ビルドでパッケージをインストールするときに apt や好みにより aptitude を制御するオプションもいくらかあります。プロキシを使っていたり、推奨パッケージのインストールを無効にして容量を節約したい、インストールするパッケージのバージョンをAPTのピン経由で制御する必要がある、等便利だと思う場面があるかもしれません。

パッケージソース
ディストリビューション、アーカイブ領域とモード

ディストリビューションの選択は Live イメージへの収録に利用できるパッケージに最も影響があります。コード名を指定してください。${testing} バージョンの live-build では ${testing} がデフォルトになっています。現在アーカイブにある任意のディストリビューションをコード名で指定できます (詳細については{条件}#terms 参照)。--distribution オプションはアーカイブ内のパッケージソースに影響するだけでなく、サポートしている各ディストリビューションをビルドするのに必要な動作をするよう live-build に指示します。例えばunstableリリースであるsidに対してビルドする場合は:

 $ lb config --distribution sid  

のように指定します。ディストリビューションアーカイブ内で、アーカイブ領域はアーカイブを大きく分類します。Debian ではmaincontribnon-free となっています。mainに収録されるソフトウェアだけが Debian ディストリビューションの一部であり、したがってそれがデフォルトとなっています。複数指定することもできます。例えば

 $ lb config --archive-areas "main contrib non-free"  

Debian 派生物によっては --mode オプションの実験的サポートが利用できるものがあります。このオプションは Debian または未知のシステムでビルドしている場合にのみデフォルトで debian がセットされています。サポートしている派生物のどれかで lb config を実行した場合のデフォルト値はその派生物のイメージを作成するための値になります。lb config を例えば ubuntu モードで実行すると Debian 向けに代えて指定された派生物のディストリビューション名やアーカイブ領域がサポートされます。このモードはその派生物に合うように live-build の挙動も変更します。

注意: モードを追加したプロジェクトの設定については主にそのオプションのサポートユーザの担当です。${project}は最善の努力をもって開発サポートを提供はしますが、私たちは派生物を自ら開発あるいはサポートしているわけではないため、あくまで派生物プロジェクトからのフィードバックが基になります。

ディストリビューションミラー

Debian アーカイブは世界中の巨大なネットワークミラーにまたがって複製されているため、各地域の人が最高のダウンロード速度を求めて近いミラーを選択できます。--mirror-* オプションはそれぞれ、ビルドの様々な段階でどのディストリビューションミラーを利用するのかを決定します。{ビルド段階}#stages-of-the-build の繰り返しになりますがパッケージ収集段階は最小限のシステムで debootstrap により最初に chroot を構成する段階、chroot 段階は chroot を使って Live システムのファイルシステムをビルドする段階です。ミラーはこの各段階ごとにそれぞれのオプションで指定するためバイナリの段階では --mirror-binary--mirror-binary-security の値が採用され、早い段階で使っていたミラーは置き換えられることになります。

ビルド時に利用するディストリビューションミラー

ビルド時に利用するディストリビューションミラーにローカルミラーを指定するには、--mirror-bootstrap--mirror-chroot-security を以下のように指定するだけです。

 $ lb config --mirror-bootstrap http://localhost/debian/ \
          --mirror-chroot-security http://localhost/debian-security/  

--mirror-chroot で指定する chroot ミラーのデフォルト値は --mirror-bootstrap の値になっています。

実行時に利用するディストリビューションミラー

--mirror-binary* オプションはバイナリイメージ中のディストリビューションミラーの位置を決定します。このオプションは Live システムの実行中に追加のパッケージをインストールする際に利用できます。デフォルトは httpredir.debian.org で、利用できるミラーの中から特にユーザのIPアドレスを基にして地理的に近いミラーを選択するサービスになっています。これはその Live システムを利用するユーザにとって最適なミラーを予測できない場合に適切な選択です。以下の例に示すように自分専用の値を指定することもできます。この設定でビルドされたイメージはその“ミラー”が到達可能なネットワークにいるユーザにとってのみ適します。

 $ lb config --mirror-binary http://mirror/debian/ \
          --mirror-binary-security http://mirror/debian-security/ \
          --mirror-binary-backports http://mirror/debian-backports/  

追加リポジトリ

リポジトリをさらに追加して、利用できるパッケージ選択の幅を対象ディストリビューション以外にも広げられます。それにより、例えば backports や experimental、そして独自のパッケージを利用できます。追加のリポジトリを設定するには config/archives/your-repository.list.chrootconfig/archives/your-repository.list.binary ファイルを作成します。--mirror-* オプションにより、イメージのビルドの chroot 段階やバイナリ段階、つまり Live システムの実行時に利用するリポジトリを決定できます。

例えば config/archives/live.list.chroot により Live システムのビルド時に debian-live スナップショットリポジトリからパッケージをインストールできます。

 deb http://live-systems.org/ sid-snapshots main contrib non-free  

同一の行を config/archives/live.list.binary に追加すると、Live システムの /etc/apt/sources.list.d/ ディレクトリにそのリポジトリが追加されます。

こういったファイルが存在すれば自動的に処理されます。

リポジトリの署名に利用されたGPG鍵を config/archives/your-repository.key.{binary,chroot} ファイルに置くこともできます。

APTのピン止めが独自に必要な場合、APT設定行等を config/archives/your-repository.pref.{binary,chroot} ファイルに配置すれば自動的に Live システムの /etc/apt/preferences.d/ ディレクトリに追加されます。

インストールするパッケージの選択

There are a number of ways to choose which packages live-build will install in your image, covering a variety of different needs. You can simply name individual packages to install in a package list. You can also use metapackages in those lists, or select them using package control file fields. And finally, you may place package files in your config/ tree, which is well suited to testing of new or experimental packages before they are available from a repository.

パッケージ一覧

パッケージ一覧はインストールするパッケージを明確にする強力な方法です。一覧の構文では条件付けをサポートし、一覧の生成や複数の設定への適合を容易にしています。ビルド時にシェルヘルパーを使って一覧にパッケージ名を差し込むこともできます。

注意: 存在しないパッケージが指定されたときの live-build の挙動はAPTユーティリティの選択により決定されます。さらなる詳細については apt と aptitude の選択 を見てください。

メタパッケージの利用

パッケージ一覧を指示するもっとも簡単な方法は利用するディストリビューションで保守されているタスクのメタパッケージの利用です。例えば:

 $ lb config
 $ echo task-gnome-desktop > config/package-lists/desktop.list.chroot  

live-build 2.x でサポートされていた、一覧を事前定義する古い方法はこれで置き換えられました。一覧の事前定義とは異なり、タスクのメタパッケージは Live システムプロジェクト特有のものではありません。タスクのメタパッケージはディストリビューション内の専門の作業グループにより保守されているため、要求したユーザに対して提供する最善のパッケージについて、各グループでの合意を反映したものとなっています。また、一覧を事前定義する置き換えられた方法よりはるかに幅広い事例にも対応できます。

タスクのメタパッケージには全て先頭が task- から始まるため、利用できるものを簡単に判別する方法があります (名前が該当しても実際にはメタパッケージではないものもほんの一部とはいえありますが)。パッケージ名を前方一致で検索します:

 $ apt-cache search --names-only ^task-  

以上に加え、他に様々な目的を持ったメタパッケージを見つけられるでしょう。gnome-core のように他のもっと範囲の広いタスクパッケージの一部を構成するものや、education-* メタパッケージのように Debian Pure Blend の中のある個々の専門分野に特化したものもあります。アーカイブにある全メタパッケージを列挙するには、debtags パッケージをインストールして role::metapackage タグの付けられたパッケージを全て列挙させます:

 $ debtags search role::metapackage  

ローカルパッケージ一覧

列挙したものがメタパッケージであれ、個々のパッケージであれ、両方の組み合わせであれ、ローカルパッケージ一覧は全て config/package-lists/ に保存されます。この一覧は複数利用できるため、うまい具合にこの一覧自体を組み込める設計になっています。例えばある一覧は特定のデスクトップ選択時向け、別の一覧は異なるデスクトップでも簡単に使えるような関連パッケージ群を、というようにできます。これにより、パッケージ群の異なる組み合わせを最小限の手間で試したり、あるいは異なる Live イメージプロジェクトで一覧を共有する、といったことが可能になります。

このディレクトリに存在するパッケージ一覧は、処理対象とするためには後ろに .list を付ける必要があり、さらにその一覧をどの段階の対象とするのか示すためには .chroot.binary をその後に追加します。

注意: 対象とする段階の指定を追加しない場合、その一覧は両方の段階で利用されます。通常指定するのは .list.chroot で、この場合そのパッケージは Live ファイルシステムにのみインストールされ、メディア上に .deb の余計なコピーは置かれません。

ローカルバイナリパッケージ一覧

バイナリ段階の一覧を作成する場合はファイルの末尾を .list.binary にして config/package-lists/ に置きます。それにより指定したパッケージは Live ファイルシステムにはインストールされず、Live メディアの pool/ 以下に収録されます。Live ではないインストーラでこういった一覧を標準的に利用しているものもあります。バイナリ段階で chroot 段階と同一の一覧を利用したい場合は上述したように末尾を .list とします。

生成されたパッケージ一覧

一覧の構成はスクリプトで生成するのが最善の方法だということもあります。感嘆符から始まる行は全て、そのコマンドがイメージのビルド後に chroot 内で実行されることを示します。例えばパッケージ一覧に ! grep-aptavail -n -sPackage -FPriority standard | sort という行を書いておけば、Priority: standard で利用可能なパッケージをソートした一覧を生成できます。

実際、パッケージの選択に grep-aptavail コマンド (dctrl-tools パッケージに収録) はとても有用なので、live-build では便宜のため Packages 補助スクリプトを提供しています。このスクリプトは引数をフィールドパターンの2つ取ります。一覧を作成する例:

 $ lb config
 $ echo '! Packages Priority standard' > config/package-lists/standard.list.chroot  

条件付き内部パッケージ一覧の利用

config/* (LB_ が先頭に付くものは除く) に保存された live-build の設定変数はどれもパッケージ一覧の条件文で利用できます。一般には lb config オプションを大文字に、ダッシュ文字をアンダースコアに変更したものになります。しかし実際に意味があるのは、パッケージ選択に関わるもの、例えば DISTRIBUTIONARCHITECTURESARCHIVE_AREAS だけです。

例えば --architectures amd64 が指定された場合に ia32-libs をインストールする場合:

 #if ARCHITECTURES amd64
 ia32-libs
 #endif  

任意の1つを条件の値とすることもできます。--architectures i386 または --architectures amd64 のどちらかが指定された場合に memtest86+ をインストールする場合の例:

 #if ARCHITECTURES i386 amd64
 memtest86+
 #endif  

値を複数指定できる変数を条件にすることもできます。--archive-areascontrib または non-free のどちらかが指定されている場合に vrms をインストールする場合の例:

 #if ARCHIVE_AREAS contrib non-free
 vrms
 #endif  

入り組んだ条件分岐はサポートしていません。

インストール時のパッケージの削除

config/package-lists ディレクトリの末尾が .list.chroot_live.list.chroot_install のファイルにパッケージを列挙できます。Live 用とインストール用の両方の一覧が存在する場合、.list.chroot_live に列挙されているパッケージは (ユーザがインストーラを利用している場合) インストール後にフックにより削除されます。.list.chroot_install に列挙されているパッケージは Live システムとインストールされたシステムの両方に存在することになります。これはインストーラ向けの特別な調整で、設定で --debian-installer live をセットしている場合や Live システム特有のパッケージをインストール時には削除したい場合に有用かもしれません。

デスクトップ及び言語タスク

デスクトップと言語のタスクは特別で、計画性や設定が追加で必要となります。Live イメージが Debian インストーライメージとは異なる点です。Debian インストーラでは、特定のデスクトップ環境向けに用意されたメディアでは対応するタスクは自動的にインストールされます。内部に gnome-desktopkde-desktoplxde-desktopxfce-desktop タスクがあり、tasksel のメニューにはどれも出てきません。同様に言語向けタスクのメニュー項目はありませんが、インストール中にユーザが選択した言語が対応する言語タスクの選択に影響します。

デスクトップ向け Live イメージ開発時には、イメージは通常動作するデスクトップを直接ブートし、デスクトップやデフォルト言語はどちらも Debian インストーラの場合のように実行時に選択するのではなくビルド時に決められています。これは Live イメージでデスクトップや言語を複数サポートしてユーザに選択の機会を与えるようにできないわけではなく、それが live-build のデフォルトの挙動ではないというだけです。

言語特有のフォントや入力メソッドにどのパッケージを収録するのか、といった規定は言語タスクにはないので、特定のパッケージを収録したい場合は設定で指定する必要があります。ドイツ語サポートを収録した GNOME デスクトップイメージの場合に収録するタスクのメタパッケージの例:

 $ lb config
 $ echo "task-gnome-desktop task-laptop" >> config/package-lists/my.list.chroot
 $ echo "task-german task-german-desktop task-german-gnome-desktop" >> config/package-lists/my.list.chroot  

カーネルのフレーバー (種類) とバージョン

アーキテクチャによっては、イメージに複数のカーネルをデフォルトで収録することができます。フレーバーは --linux-flavours オプションで選択できます。各フレーバーはデフォルトの短い linux-image に、イメージに収録される実際のカーネルパッケージに依存する各メタパッケージの名前を付加した形式になります。

そうして、デフォルトで amd64 アーキテクチャのイメージは linux-image-amd64 のメタパッケージを収録し、i386 アーキテクチャのイメージは linux-image-586 メタパッケージを収録します。

設定したアーカイブで複数バージョンのカーネルパッケージが利用できる場合、--linux-packages オプションでカーネルパッケージ名の前半部を指定できます。例えば amd64 アーキテクチャのイメージをビルドする際にテスト用に experimental アーカイブを追加すると linux-image-3.18.0-trunk-amd64 カーネルをインストールできます。そのイメージの設定例:

 $ lb config --linux-packages linux-image-3.18.0-trunk
 $ echo "deb http://ftp.debian.org/debian/ experimental main" > config/archives/experimental.list.chroot  

独自のカーネル

Debian パッケージ管理システムに組み入れられていれば、独自のカーネルを自分でビルド、収録できます。live-build システムは .deb パッケージでビルドされていないカーネルはサポートしていません。

自身のカーネルパッケージを配置するための適切で推奨する方法は kernel-handbook の指示に従うことです。パッケージ名のABIとフレーバーの部分を忘れずに適切に変更し、リポジトリに linux の完全なビルドとそれに該当する linux-latest パッケージを収録してください。

該当するメタパッケージ無しでカーネルパッケージをビルドしたい場合は、{カーネルのフレーバー (種類) とバージョン}#kernel-flavour-and-version で説明しているように --linux-packages でパッケージ名の適切な前半部を指定する必要があります。{変更したあるいはサードパーティ製パッケージのインストール}#installing-modified-or-third-party-packages で説明しているように、自身のリポジトリに独自のカーネルパッケージを収録する場合はそのようにするのが最善ですが、別の方法についても説明しています。

カーネルを独自化する方法はこの文書の対象範囲ではありません。とはいえ、設定が最低限満たさないといけない要件があります:

●  初期RAMディスクを利用する。

●  結合ファイルシステムモジュール (つまり通常は aufs) を収録する。

●  自分の設定で必要とする他のファイルシステムモジュール (つまり通常は squashfs) があればそれを収録する。

変更したあるいはサードパーティ製パッケージのインストール

Live システムの哲学には反しますが、Debian リポジトリにあるバージョンのパッケージを改変して Live システムをビルドする必要に迫られることもあります。それは機能や言語、商標を変更あるいは追加するものであったり、既存のパッケージから望ましくない要素を削除するものであるかもしれません。同様に求める機能や独自開発の機能を追加するのに「サードパーティ製」パッケージを利用できます。

この節では変更したパッケージのビルドや保守については対象としていません。Joachim Breitner さんの http://www.joachim-breitner.de/blog/archives/282-How-to-fork-privately.html にある「How to fork privately」に書かれている方法が該当するのかもしれませんが。求める機能を収録したパッケージの作成については https://www.debian.org/doc/maint-guide/ にある Debian 新メンテナーガイドその他で説明されています。

変更した独自のパッケージをインストールする方法は2つあります:

●  packages.chroot

●  独自APTリポジトリの利用

packages.chroot を使う方法はより簡単に出来て「一度限りの」独自化には有用ですが欠点がいくつかあります。一方独自のAPTリポジトリを使う方法はその準備に時間がかかりまます。

packages.chroot を利用した独自のパッケージのインストール

独自化したパッケージをインストールするには、単にconfig/packages.chroot/ ディレクトリにコピーします。このディレクトリ内に置かれたパッケージはビルドの際に Live システムに自動的にインストールされます - 他のどこかを指定する必要はありません。

パッケージ名は規定の命名規則に従わないといけません。それを簡単に行う方法は dpkg-name の利用です。

packages.chroot を利用した独自のパッケージのインストールには欠点があります:

●  secure APT を利用することができません。

●  config/packages.chroot/ ディレクトリに適切なパッケージを全てインストールしないといけません。

●  Live システムの設定をリビジョン管理するには適しません。

APTリポジトリを利用した独自パッケージのインストール

packages.chroot を使う場合とは異なり、独自のAPTリポジトリを使う場合は他のどこかでパッケージを指定する必要があります。詳細については{インストールするパッケージの選択}#choosing-packages-to-install を見てください。

独自のパッケージをインストールするためにAPTリポジトリを作成するのは不要な手間だと思うかもしれませんが、その基盤は変更したパッケージを後で更新する際に簡単に再利用できます。

独自パッケージとAPT

live-build は Live システムへのパッケージのインストールに全てAPTを利用するため、そのプログラムの挙動を引き継ぎます。関連する一例としては (デフォルト設定だと仮定して)、異なる2つのリポジトリでバージョン番号の異なるあるパッケージが利用可能な場合に、APTはバージョン番号の大きい方のパッケージをインストールに選択します。

そのため、独自パッケージの debian/changeLog ファイルでバージョン番号を増加させ、公式の Debian リポジトリにあるものよりも変更したバージョンが確実にインストールされるようにすると良いでしょう。Live システムのAPTのピン設定を改変する方法もあります - さらなる情報については、{APTのピン止め}#apt-pinning を見てください。

ビルド時のAPT設定

ビルド時だけに適用されるオプションを使ってAPTを設定できます (実行中の Live システムで利用されるAPTの設定は Live システムの内容による通常の、config/includes.chroot/ で適切な設定を収録する) 方法により設定できます。オプションの全容については lb_config man ページの apt で始まるオプションを見てください。

apt と aptitude の選択

ビルド時にパッケージをインストールする際に aptaptitude のどちらを利用するのか選択できます。利用するユーティリティは lb config--apt 引数で決定します。パッケージが欠けている場合の処理方法に顕著な違いがあることに着目し、パッケージのインストール時に望ましい挙動を実装している方を選択してください。

●  apt: この方法では、欠けているパッケージが指定された場合にそのパッケージのインストールは失敗します。これはデフォルトの設定です。

●  aptitude: この方法では、欠けているパッケージが指定された場合にそのパッケージのインストールは成功します。

APTでのプロキシの利用

よく要求されるAPTの設定として、プロキシの内側でのイメージのビルドへの対応があります。必要に応じて、--apt-ftp-proxy--apt-http-proxy オプションによりAPTプロキシを指定できます。例:

 $ lb config --apt-http-proxy http://proxy/  

APTの調整による容量節約

イメージのメディアの容量をいくらか節約する必要があるかもしれません。その場合は以下に挙げるオプションを利用するといいかもしれません。

APTの索引をイメージに収録したくない場合は除外できます:

 $ lb config --apt-indices false  

これは /etc/apt/sources.list 内の項目には影響せず、単に /var/lib/apt に索引ファイルを収録するかどうかだけに影響します。その代わりに、Live システムでAPTを操作するためにはこの索引が必要なので、apt-cache searchapt-get install を実行する前にユーザは例えば apt-get update をまず実行して索引を作成しないといけません。

推奨パッケージのインストールによりイメージが肥大化しているような場合、以下で説明している影響を踏まえた上でAPTのデフォルトオプションを無効にできます:

 $ lb config --apt-recommends false  

推奨パッケージを無効にした場合の最も重要な影響は、live-bootlive-config 自体が、ほとんどの Live 設定に利用している重要な機能を提供する一部のパッケージを推奨していることによるもので、例えば live-config が推奨し、Live ユーザの作成に利用している user-setup があります。ほぼ例外なく、パッケージ一覧に追加しないといけないパッケージが推奨パッケージの中にいくらかあります。追加しない場合は、イメージが期待通りに動作しないということになります。ビルドに収録されている各 live-* パッケージの推奨パッケージを確認し、省略できると確信できない場合はパッケージ一覧に当該パッケージを追加するようにしてください。

あるパッケージの推奨パッケージをインストールしないことによるもっと一般的な影響は「異常なインストール状態でなければあるパッケージとともにあるはずの」(Debian ポリシーマニュアル7.2節) Live システムのユーザが実際に必要とする一部のパッケージが省略されているかもしれないということです。したがって、推奨パッケージのインストールを無効にした場合とのパッケージ一覧 (lb build により生成される binary.packages ファイル参照) の違いを確認して、欠けているパッケージの中にインストールしたいものがあれば一覧に収録することを推奨しています。推奨パッケージからほんの一部を除外したい場合は、推奨パッケージのインストールは有効なままにしておき、{APTのピン止め}#apt-pinning で説明しているようにAPTのピン機能で、選択したパッケージについて負の優先度をセットしてインストールされないようにする方法があります。

apt や aptitude へのオプションの受け渡し

障害となるAPTの挙動を変更するための lb config オプションがない場合、--apt-options--aptitude-options により任意のオプションを選択したAPTツールに渡せます。詳細については aptaptitude の man ページを見てください。どちらのオプションにも、優先設定に加えて保持しておく必要のあるデフォルト値があることに注意してください。そのため、例えば snapshot.debian.org からテスト用に何か取得する場合に Acquire::Check-Valid-Until=false を指定するとAPTは古いままの Release ファイルを使い続けます。以下の例のように、デフォルト値 --yes の後に新しいオプションを付加します:

 $ lb config --apt-options "--yes -oAcquire::Check-Valid-Until=false"  

このオプションを利用する場合は man ページを確認して完全に理解するようにしてください。これはあくまで例であり、イメージをこの方法で設定するようにという助言だと解釈することのないようにしてください。このオプションは例えば Live イメージの最終的なリリースには適しません。

apt.conf のオプションを利用するようなもっと複雑なAPT設定には代わりに config/apt/apt.conf ファイルを作成すると良いでしょう。少数ですが、よく必要とされるオプションへの有用なショートカットがあります。他の apt-* オプションについても参照してください。

APTのピン止め

背景として、apt_preferences(5) man ページをまず読んでください。APTのピン機能はビルド時用と実行時用に設定できます。前者については config/archives/*.prefconfig/archives/*.pref.chrootconfig/apt/preferences を、後者については config/includes.chroot/etc/apt/preferences を作成してください。

${testing} の Live システムをビルドするとしましょう。その場合に必要な Live パッケージは全て、ビルド時にバイナリイメージを sid からインストールする必要があります。APTソースに sid を追加して、ピン機能で sid の Live パッケージには高い優先度をセットし、他のパッケージには全てデフォルトよりも低い優先度をセットする必要があります。そうするとビルド時に望むパッケージだけを sid からインストールし、他は全て対象システムのディストリビューションである ${testing} から取得します。以下によりその動作になります:

 $ echo "deb http://mirror/debian/ sid main" > config/archives/sid.list.chroot
 $ cat >> config/archives/sid.pref.chroot << EOF
 Package: live-*
 Pin: release n=sid
 Pin-Priority: 600

 Package: *
 Pin: release n=sid
 Pin-Priority: 1
 EOF  

別のパッケージにより推奨されたパッケージを望まない場合に、ピン機能で優先度に負の値をセットすることによりそのパッケージをインストールしないようにできます。config/package-lists/desktop.list.chroottask-lxde-desktop を使って LXDE イメージをビルドしていて、wifi パスワードをキーリングに保存するかユーザに聞かないようにしたいと仮定しましょう。このメタパッケージは lxde-core に依存し、lxde-coregksu を推奨し、gksugnome-keyring を推奨しています。そこで、推奨された gnome-keyring パッケージを除外したい場合、config/apt/preferences に以下を追加することで除外できます:

 Package: gnome-keyring
 Pin: version *
 Pin-Priority: -1  



License: This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/.

The complete text of the GNU General Public License can be found in /usr/share/common-licenses/GPL-3 file.


≅ SiSU Spine ፨ (object numbering & object search)

(web 1993, object numbering 1997, object search 2002 ...) 2024