Debian、merged-/usr を延期 42
ストーリー by headless
延期 部門より
延期 部門より
Debian プロジェクト技術委員会は 16 日、merged-/usr を Debian 12 では延期すると発表した
(メーリングリストでのアナウンス、
Phoronix の記事)。
merged-/usr (UsrMerge) はルートファイルシステムのディレクトリ (bin・sbin・lib) を /usr 以下のサブディレクトリへ移動し、ルートファイルシステムにはそのシンボリックリンクを置くというものだ。Debian 11 では merged-/usr と non-merged-/usr が混在しているが、Debian 12 ですべてを merged-/usr へ移行する計画が 2021 年に示されていた。しかし、マージ後の /usr ファイルシステムのレイアウトの状態や、既存の Debian 11 に対するアップグレードパスの扱いに関する開発者からの疑問がいくつか解決していなかったという。
今回技術委員会では採決の結果、次の採決で取り消されるまで merged-/usr 実施の延期を決定した。個別のプロジェクトのメインテナーに対しては、早まってルートファイルシステムからファイルを /usr に移動しないことを推奨し、Debian 12 リリース時点で /usr・/bin・/lib*・/sbin の各ディレクトリに格納されていたファイルはそれぞれのディレクトリ内にとどまり、Debian 12 リリース後に /bin・/lib*・/sbin から /usr へ移動したファイルは元の場所に戻されるべきとのこと。
次の採決は Debian 13 "Trixie" の開発サイクル内で行う見込みとのことだ。
merged-/usr (UsrMerge) はルートファイルシステムのディレクトリ (bin・sbin・lib) を /usr 以下のサブディレクトリへ移動し、ルートファイルシステムにはそのシンボリックリンクを置くというものだ。Debian 11 では merged-/usr と non-merged-/usr が混在しているが、Debian 12 ですべてを merged-/usr へ移行する計画が 2021 年に示されていた。しかし、マージ後の /usr ファイルシステムのレイアウトの状態や、既存の Debian 11 に対するアップグレードパスの扱いに関する開発者からの疑問がいくつか解決していなかったという。
今回技術委員会では採決の結果、次の採決で取り消されるまで merged-/usr 実施の延期を決定した。個別のプロジェクトのメインテナーに対しては、早まってルートファイルシステムからファイルを /usr に移動しないことを推奨し、Debian 12 リリース時点で /usr・/bin・/lib*・/sbin の各ディレクトリに格納されていたファイルはそれぞれのディレクトリ内にとどまり、Debian 12 リリース後に /bin・/lib*・/sbin から /usr へ移動したファイルは元の場所に戻されるべきとのこと。
次の採決は Debian 13 "Trixie" の開発サイクル内で行う見込みとのことだ。
systemd使いは大変だなぁ（棒読み (スコア:2, 参考になる)
スラドって基本的にしったか君しかいないよね？
ここまで「なぜ今merged-/usrする必要があるのか？」の情報ゼロだよ
原因を明らかにしないまま、しったかコメントだけが続いてゆく
ヤバイ場所だよまったく
これが理由 [freedesktop.org]ですからね(笑)
Debian 12でのmerged-/usrは延期ということは、つまりDebian 12では今年後半以降にリリースされるsystemdからは、それをそのまま使うことができないということ
古いsystemdを使い続けるか、あるいは自分達でこねくりまわして強引に動かすしかない
だから言ったのに
Debianのような懐古主義者だらけのディストリでsystemd全面採用は危険だと
ただちに必要だったのはとりまsystemd-udevdとsystemd-logindだけだったのだから、systemd-udevd単品使い＆elogind使って茶を濁し、init含めその他一式はそのままにしておけと
それをあえてsystemd全面採用強行した結果がこのザマだよ
反対派の予想通りにsystemdに振り回されまくってやがる(笑)
おかげでGNOME/KDE使ってないどころか、X.org自体使う必要がない連中まで、この手の騒ぎが起きる度に巻き添え食らってるじゃん？
Raspbianみたいに、リソース限られてて基本シリアルコンソールで使う前提のディストリまで巻き添えよん？
バカジャネーノ？
＃ どの業界においても上が先見性皆無だと大変だ
Re:systemd使いは大変だなぁ（棒読み (スコア:2, 参考になる)
＞スラドって基本的にしったか君しかいないよね？
ほんとだねえ。君なんかありもしない問題に心を砕いてて大変そうだ。
そもそも新規インストール組はdebian 10の時点でmerged /usrしてる [debian.org]。
パッケージレベルでは/binとかの旧来ディレクトリに突っ込まれるが、実ファイルはシンボリックリンクになってる/binとかを通って/usr以下に置かれてる。
debian 13以降に延期になったのはアップグレード組を含めた全ユーザーに対するmerged /usr強制（パッケージレベルで/usr以下にファイルを突っ込むとか）だ。
systemdも merged-/usrも普通に動いてます (スコア:3)
アップグレード組でも usrmerge というパッケージを入れるだけで自動で merged usr な環境に切り替わります。
手元のdebianは全部移行済み。systemdやXも含めて特に不都合は起きてません。
Re: (スコア:0)
> そもそも新規インストール組はdebian 10の時点でmerged /usrしてる [debian.org]。
なるほどそういうことか。
うちがまさにそれで、なんか噛み合わないと思ったんだ。
Re: (スコア:0)
全員が必要だったのはsystemd-udevdだけでX11関連使わないならelogindすら入れる必要なかったのにバカばっかだよまったく…
馬鹿馬鹿しくて笑えてくる
Re:systemd使いは大変だなぁ（棒読み (スコア:1)
てかsystemdがudevマージしたから仕方なくsystemd-udevdが必要になってるだけで、昔みたいにudevはsystemdから分離してたならインフラ屋の我々はsystemd入れる必要すら無かったのがまた…
＃ アカン、もはや愚痴しか出てこない
Re: (スコア:0)
物理・仮想マシンでSystemdがあるのは受け入れる。だが、DebianのDocker公式イメージにlibsystemd.soが入っているのはどうにかしてほしい。実行時には不要なのにその辺りのパッケージで数十MBも余計にサイズを増やしている。
Re: (スコア:0)
なるほど参考になる。
ついでに、ファイルを移動してシンボリックリンクを貼るだけのことでなんで揉めてるのかも解説してくれ。
Re: (スコア:0)
そもそもなんで移動する話になったのかもお願いしたい。
systemdの何がいいのかわかんないおいちゃん、そういうのAs isでいいじゃんと思っちゃうので。
Re: (スコア:0)
systemdのプログラムとしては、#if HAVE_SPLIT_USRの分岐がなくなりテストするパターンが減る、保守コスト低減（言い換えればそれだけ）だと思われる。
Booting Without /usr is Broken [freedesktop.org]では、Systemd以前からudevルールの一部などブート時（initdから/initに移った時点）に/usrマウントが必要という状況だった（Systemd自体は/usrなしでもいけるけど）と述べられている。Systemdとしては、merged-/usrで多くのディストリビューションがうまくやっているみたいという状況に乗っかって、もうmerged-/usrだけでいいでしょうと考えているということなのだろう。
Re: (スコア:0)
確か、「UDEV を人質に取られて・・・」って言い方をされてたよね。ホントにそう思う。
Devuan [devuan.org]ってのも、まあ、あるけど
Re: (スコア:0)
智慧あるものよ教えてくれ。systemdがmerged-/usrでないと動作しなくなるわけを。systemdがコンテナ機能を支配下に置く野望を抱いたが、コンテナを小さく保つためにコンテナの/usrはベースOSの/usrをそのまま使用するからだという噂を聞いたが、本当なのか。
つまり、systemdはすべてを同化しようとするソフトウェア界のボーグあるいはフェストゥムであるということなのか。
Re: (スコア:0)
参考になります。ちなみにsystemd全面採用は危険だとのご発言をされたのがメーリングなどでしたら、過去ログへのリンク等を教えていただけますか？ディスカッションの成り行きを確認したいです。
Re: (スコア:0)
古いsystemdを使い続けるか
Debianはそれが平常運転でしょ。たとえばDebian 11 BullseyeではSystemd 247が採用されたので、Debian 11ではEOLまで基本ずっとSystemd 247。
Backportsという例外はあるけど。
あるいは自分達でこねくりまわして強引に動かすしかない
Debianならやってもおかしくはない。Debian 11のBackportsではunmerged-/usr対応に戻すパッチ付きでもっと新しいsystemdをビルドするのもあり得ると思っている。
強引と感じる程度は人それぞれだろうけど、unmerged-/usr対応リバートのパッチくらい作ってもおかしくないと思う。今でもDebianはSystemdに
Re: (スコア:0)
あ、書き間違えた。「Debian 11のBackportsでは」じゃなくて「Debian 12のBackportsでは」と書きたかった。すまない。
Re: (スコア:0)
根本的に認識齟齬があるようですね。
Debianは最も先進的で挑戦的なグループの一つだからsystemdを採用したと私は思います。
様々なトラブルに対しても怯まない姿勢があります。
それでいて、多様な利用者への配慮も欠かさない面もあります。
多分、「あなたの知っている人が懐古主義者だった」というだけではないでしょうか？ Debianは常に挑戦的に先進を目指していますよ。その結果として、乗り遅れる人や方向性の相違もでてきて、不平不満な見解がでてくるということかと思います。
# まあ、よくある女に振られた（愛想尽かされた）男が女の悪口を言うのと同じですね。
Re: (スコア:0)
Debianは先進的でも懐古的でもなく保守的だと思います。
複雑だな (スコア:0)
(1) merged-/user
(2) merged-/usr
(3) non-merged-/usr
があって、(1)と(3)は混在していて、(2)へ移行する計画が2021年に示されていて、
(2)実施の延期を決定したんだ。
それでメンテナーには/userへの移動をしないことを推奨して、
Debian12リリース後に/userへ移動されたファイルはもとに戻される。
わけがわからん。
とりあえずおれのDebian testingは/sbin, /bin, /lib*は/usr/*へのシンボリックリンクだな。
usrmergeパッケージはインストールしている。
Re:複雑だな (スコア:1)
違うよ。全然違うよ。 (スコア:0)
> (1) merged-/user
> (2) merged-/usr
> (3) non-merged-/usr
> があって、(1)と(3)は混在していて、(2)へ移行する計画が2021年に示されていて、
> (2)実施の延期を決定したんだ。
(1) merged-/user なんてものは存在しない。そう、君はいつも通り headless に騙されたんだ。
Re: (スコア:0)
(1) merged-/user なんてものは存在しない。そう、君はいつも通り headless に騙されたんだ。
きっと移動先がC:\Usersの話なんだよ
WSLの主流をUbuntuから奪い去るための壮大な計画が明らかに!?(ヾﾉ･∀･`)ﾅｲﾅｲ
何年も前にFedoraがやったことの後追い (スコア:0)
なのに時間かけすぎ
Re:何年も前にFedoraがやったことの後追い (スコア:2, 興味深い)
Fedora のアップデートで壊れても誰も怒らないじゃん
Debian でアレをやったらめっちゃキレられる
Re: (スコア:0)
ないすボタン押したくなったよ
Re:何年も前にFedoraがやったことの後追い (スコア:1)
https://fedoraproject.org/wiki/Features/UsrMove [fedoraproject.org]
2012年には完了してるんですよね。debianはなぜ失敗したんだろう？
いっその事 (スコア:0)
/Program Files 以下に置いてはどうか
Re: (スコア:0)
/Program Files 以下に置いてはどうか
marged-systemdで/をsystemdに当てるのが先でしょう
更にcpuなど物理領域へ侵食しその後でmarged-userするんですよ
Re: (スコア:0)
話は変わるけど、最近Systemdの浸食を感じたのは、initramfsの中にsystemdが入っているパターンがあるということ。
Re: (スコア:0)
/Program Files (86) : 私のこともお忘れなく
Re: (スコア:0)
/Program Files (x86): なんだそのパチもの
Re: (スコア:0)
#!/bin/sh
d="/Program Files"
cd $d
Re: (スコア:0)
cd: too many arguments
パッケージ (スコア:0)
静的なファイルを/usrにまとめるのはいいんだけど、パッケージとベースインストールを混ぜこぜにするのはどうにかなりませんかね？
FreeBSDみたいにパッケージを専用ディレクトリに入れてればmajor upgradeとかも楽だと思うんだけど。
でも最近のファイルシステムだとスナップショットとかOverlayFSがあるから、今からならそっちでええやんって話なのかな？
Re:パッケージ (スコア:1)
/usr/localって別にpkg/ports専用ディレクトリではないからなぁ
portsと無関係で自前でmakeしたのも普通は/usr/localに入るし
Re: (スコア:0)
debianにパッケージ外のベースインストールってあるの？
Re: (スコア:0)
ないと思う。ちなみに、FreeBSDもベースやカーネルをパッケージシステムで提供することを実験している。
https://wiki.freebsd.org/PkgBase [freebsd.org]
やはりLinuxデスクトップは普及しそうにない (スコア:0)
もうシェア取るの諦めてるんじゃないの
Re: (スコア:0)
Macもそうだけど、やはり理想を追い求め過ぎなんだろうか
なんか違う (スコア:0)
昔から思ってるんだけど、廃止するのは /use/bin であるべきで /bin じゃないだろうと思う。lib とか他も同じ。
歴史的にいって /bin, /lib, /etc にはシステム標準のコマンドが配置され
/usr 以下にはユーザーの作成したコマンドが置かれていた。だから名前が usr なわで。
その後 BSD とかで追加されたコマンドを /usr 以下に配置して配布されるようになって、/usr/local が作られて、
/var が /usr から分離されて、という経緯なので、整理するんなら /usr 廃止なんじゃないかと
Re: (スコア:0)
そうはいっても30年くらいまえのSunOSでもシングルユーザーモードに必要なもの以外は
/usrに入れるくらいの考え方だったと思います。
/usrはNFS RO 共有マウント可能で、/は/usrをマウントできるくらいのコマンドがあればよい。
ネットブートかつ/をNFSにするのもありましたけどね。
おそらく/usrに全部入れるというのは/usrがRO共有マウント可能というところから
派生した考えであって、initramfsがあるLinuxからすると不思議な考えでは無い気もします。
マウントポイントは1つのほうがいいですよね。
Re: (スコア:0)
The Case for the /usr Merge [linux.srad.jp]には、/usrをネットワークからマウントしている環境の話がある。あとページの下のほうに/のほうがいいんじゃない？という件に対する反論も書かれている。
Re: (スコア:0)
自己レス。すまん、リンク間違えた。正しくはThe Case for the /usr Merge [freedesktop.org]