パッケージ管理

入れたはずなのに、古い版が入る

新しく借りたサーバーで、必要なコマンドを 1 つ入れようとして Unable to locate package と断られる。あるいは入ったものの、手元より何年も古い版だった。どちらも、同じ原因で起きます。

パッケージマネージャは、インターネットを毎回探しに行くわけではありません。手元に持っている目録を見て、そこに載っている場所から取ってきます。借りたばかりのサーバーの目録は、イメージが作られた日のまま止まっています。

前の 1 行が目録の取り直し、後ろの 1 行が導入です。この 2 つは必ず組で打ちます。-y は確認への返事を省く指定で、自動化するときには必要ですが、手で打つときはあえて外し、何が入るのかを読んでから通す方が安全です。

系統ごとに名前が違うだけで、考え方は共通です。

1 つ入れたつもりが、何十個も入る

パッケージは単体では動きません。必要なライブラリを芋づる式に連れてきます。そのため「小さなツールを 1 つ」のつもりが、数百 MB を占めることがあります。実行する前に、何が起きるかを見ておきます。

--dry-run を付けると、実際には入れずに、入る予定のものだけを並べてくれます。ディスクの残りが少ないサーバーや、構成を変えたくない本番環境では、この確認を挟んでください。

本番で apt upgrade を素で打たない

apt upgrade は、入っているものすべてを新しくします。手元の開発機なら歓迎ですが、動いているサーバーでは話が変わります。アプリが前提にしているライブラリまで上がり、再起動したときに立ち上がらなくなる、という止まり方をします。

目的が 1 つのパッケージの更新なら、対象を指定します。

逆に、上げてほしくないものには印を付けておけます。

hold を付けたパッケージは、全体の更新からも外れます。版を固定したい理由があるときに使い、外すときは unhold に替えます。

なお、Python や Node.js のライブラリは、OS のパッケージ管理とは別の仕組みで入れます。両方から同じものを入れると、どちらが使われているのか分からなくなります。OS の道具は OS の管理で、アプリのライブラリは言語側の管理で、と分けておいてください。