PostgreSQL18ベータ3をDebian(bookworm)にインストールする手順

PostgreSQL18ベータ3がリリースされた
https://www.postgresql.org/docs/18/

早速、インストール手順をまとめてみた。Debian12用なのでUbuntuも同じハズ。
それ以外の環境は Out of 眼中

VirtualBox上のインスタンスとしてスクラップ＆ビルドして遊んでみる。

作業は適当なユーザをsudoersに追加してから行った。
おすすめしないが、rootユーザで直接作業するときは先頭のsudoを外す。

まずは作業前のOSを最新化して、ネットワークの正常性も確認しておく。

sudo apt update
sudo apt upgrade

次にsource.listにpgdg.listを追加する。（以下は1行）

sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main 18" > /etc/apt/sources.list.d/pgdg.list'

リポジトリキーを追加する。（これも1行）

sudo wget -qO- https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo tee /etc/apt/trusted.gpg.d/pgdg.asc &>/dev/null

動作確認してみる。

sudo apt update
sudo apt upgrade

エラーがないならパッケージを確認。

sudo apt list postgresql-17
sudo apt list postgresql-18

どっちも存在する！

では18をインストール。

sudo apt install postgresql-18
sudo apt install libpq-dev

じゃあ、postgresユーザでpsqlを実行して…
PostgreSQL18の世界へようこそ。

YOLO12物体検出環境はDebian GNU/Linuxで

YOLO12物体検出とかGNUライセンスな製品試すのに、Debian GNU/Linux使わない不思議な人が多すぎ。
（Ubuntuでもいいけど）

sudoersに作業ユーザ追加してから、なぜか標準じゃ入らないsshdを入れる。
  sudo apt install openssh-server
そうしたら、
  sudo apt install python3 python3-pip python3-venv
してから仮想環境に入る。
  python3 -m venv venv
  source venv/bin/activate

仮想環境内でpipのバージョン上げて
  python3 -m pip install --upgrade pip

Ultralyticsのインストール
  pip install ultralytics

たったのこれだけ。実際には確認コマンドも発行するけど基本的にこれだけ。
テストもこの1行。
  yolo task=detect mode=predict model=yolo12n.pt source="https://ultralytics.com/images/bus.jpg" save=True save_txt save_conf

しかもこの手順、YOLOv8からYOLO12まで共通

でも、DebianとVirtualBoxってクセがある気が。

仮想サーバの画面が固まりやすい。ビデオメモリを最大にして回避できたりできなかったり。

Ubuntuだと小細工なしに問題無いっぽいから、何かひと手間必要かも。いや、同じかも。

まぁここは、気が向いたら調べよう。

たぶん両方の環境のパッケージの差を見ればわかるから。

ついでに調べとけよオレ

パッケージ管理

インストールパッケージ一覧として、数千ものファイル名が載った納品物が世の中には存在する。
数千もの細かなファイル名の羅列を見ても、何がインストールされているのかよくわからない。

管理すべきはOS名とパッケージ名と、そのバージョンとリビジョンである。
前提として、CPUアーキテクチャも必要だが。

例えばnginxのRedHetEL9.xのx86_64版のリリースxxというだけで、構成ファイル一覧を取得できる。
使うのはパッケージ管理ツールyum(dnf)だ。

yumにhistoryオプションを指定すると、インストールやアップデートの実施日時と概要がわかる。

概要一覧の先頭のIDを指定して、「yum history info <ID>」を実施すると、コマンドと引数の履歴がわかる。
さらには、依存関係を解決して実際にインストールされた複数のrpmファイルの一覧が表示される。

ここで有用なのは、rpmファイルの一覧ではなく、yum の操作ログなのである。
インストールやアップデートしたパッケージ名さえあれば、前提ファイルの類は意識しなくても済む。

OS以外が準備した、remiやepelなどのリポジトリを指定する場合も同じ。
表示される一覧に、リポジトリの詳細もついてくる。

サーバ更改で新システムのOSを最新に上げる場合、必要なのは現行システムの構成ファイル一覧ではなく、
実際に操作したyumの履歴のほうである。せいぜい20行程度のハズなので。


では、yumを使わずにrpmで直にインストールしたパッケージはどうするか。
yumの履歴には無いが、実際には存在しているパッケージだ。

実は、rpmにも履歴管理オプションはある。「rpm -qa --last」などである。
依存関係の管理はされていないが、ファイルの更新日時の記録が取れるので、
yumの履歴と突き合わせれば差分がわかる。

ソースから直に野良ビルドしていない以上、比較的簡単に正確な作業ができる。


ここで問題になるのは、インターネットに繋がっていないサーバ群だ。
方法は、ざっくり2つ。

 1.インストールやアップデートの時だけ、各リポジトリとの通信経路を確保する
 2.各リポジトリのミラーサーバをLAN内に配置する

1は、更新時にルータの電源の入/切などの運用で実現する。
2は、WSUSサーバのようなものを構築する方法だ。

いずれにせよ、この運用形態が確立しないまま、rpmファイルを手作業でインストール
していると、せっかくのパッケージ管理の恩恵を失うことになる。