Tweet
Tweet

Slide 1

Slide 1 text

mikutter メンテから見る pkgsrc システム紹介 mikutter Nagoya 2018.5 #toshiakaigo2018 Izumi Tsutsui tsutsui@NetBSD.org Mastodon: @tsutsuii@social.mikutter.hachune.net Twitter: @tsutsuii

Slide 2

Slide 2 text

普段は書かないので去年のmikutter会議の使いまわしですが とりあえず 自己紹介

Slide 3

Slide 3 text

@tsutsuii ✔ NetBSD 開発者 (but not プログラマ) ➢tsutsui@NetBSD.org ➢いわゆる「謎マシン」担当  NetBSD/news68k SONY NEWS  NetBSD/hp300 HP 9000/300  NetBSD/luna68k OMRON LUNA 等々

Slide 4

Slide 4 text

mikutter と @tsutsuii ✔ mikutter歴： 7年くらい ✔ pkgsrc の mikutter のメンテナも やってます

Slide 5

Slide 5 text

pkgsrc とは  www.pkgsrc.org より pkgsrc is a framework for building third- party software on NetBSD and other UNIX-like systems, currently over 17000 packages. It is used to enable freely available software to be configured and built easily on supported platform.

Slide 6

Slide 6 text

pkgsrc 概要① ●1997年 FreeBSD portから fork ●NetBSD標準のパッケージシステム ●NetBSD以外のシステムもサポート ✔Linux, FreeBSD, OpenBSD, IRIX, AIX, DragonflyBSD, OSF/1, HP-UX, QNX, Haiku, MirBSD, Minix3, Cygwin … ただし最初に動いたあとは放置というパターンもありがち ●pkgsrc-2018Q1 では 18000パッケージ

Slide 7

Slide 7 text

pkgsrc 概要② ●基本は「ソースを取得してビルド」 ➔イメージで言うと Gentooに近い？ ●バイナリパッケージのしくみもある ●が、マンパワー・マシンパワー不足で バイナリパッケージの供給が遅かったり 依存関係解決がいまいちだったり ●さらに、最新は NetBSD 7.1.2 なのに 7.0 7.1用のバイナリしか作ってない、とか ユーザーの利便性より開発者の思想優先という感じ

Slide 8

Slide 8 text

pkgsrc/net/mikutter ●2011年4月5日 mikutter 0.0.2.12 が pkgsrc ツリーにインポートされる ●その時のコミットログ

Slide 9

Slide 9 text

pkgsrc/net/mikutter ●のちにこれを見たとしぁさんのコメント ●現在の git repository の README等には 同様の記載は残っていない模様…… ●今は普通(?)の記載に戻っています

Slide 10

Slide 10 text

pkgsrcファイル  pkgsrc/net/mikutter の中身 $ pwd /home/tsutsui/pkgsrc/net/mikutter $ ls -l total 124 drwxr-xr-x 2 tsutsui users 512 Apr 3 05:11 CVS -rw-r--r-- 1 tsutsui users 106 May 15 2013 DESCR -rw-r--r-- 1 tsutsui users 2632 Mar 9 23:37 Makefile -rw-r--r-- 1 tsutsui users 48326 Feb 8 23:55 PLIST -rw-r--r-- 1 tsutsui users 763 Mar 9 23:37 distinfo drwxr-xr-x 3 tsutsui users 512 Apr 3 05:11 files drwxr-xr-x 3 tsutsui users 512 Apr 3 05:11 patches $ ls -l patches total 20 drwxr-xr-x 2 tsutsui users 512 Apr 3 05:11 CVS -rw-r--r-- 1 tsutsui users 501 Aug 14 2013 patch-core_plugin_libnotify_rnotify.rb -rw-r--r-- 1 tsutsui users 393 Jan 10 2016 patch-core_plugin_photo__support_Gemfile -rw-r--r-- 1 tsutsui users 1271 Mar 9 23:37 patch-core_plugin_photo__support_photo__support.rb -rw-r--r-- 1 tsutsui users 425 Jan 14 14:15 patch-mikutter.rb

Slide 11

Slide 11 text

pkgsrcファイル ●DESCR: パッケージ概要説明 さっきの moeeeeeeeeeee は これの中身 ●PLIST: インストールファイルのリスト ●distinfo: upstreamファイルのハッシュ ●files: pkgsrcが独自に追加するファイル mikutter の場合は起動用のシェルスクリプト ●patches: pkgsrc独自パッチ 詳細は後述

Slide 12

Slide 12 text

pkgsrc ビルド概要① ●依存関係のチェック 必要なパッケージがあれば先にビルドしてインストール ●Upstreamからソースの .tar.gz 等を取得 ●ビルド作業ディレクトリで展開 ●pkgsrc固有のパッチを当てる ●ビルドに使うツールの wrapperを用意する コンパイラやオプションの差し替えその他

Slide 13

Slide 13 text

pkgsrc ビルド概要② ●ビルドする mikutterの場合 rubyスクリプトなので実質何もしない ●作業フォルダに仮インストールする mikutter の場合 ${DESTDIR}/share/mikutter 以下に入ります ●インストールファイルと PLIST を照合 ●バイナリパッケージを作成 ●作成したパッケージで実際のインストール

Slide 14

Slide 14 text

ruby gem の扱い① ●各 gem を独立したパッケージとして登録 依存関係の多い gem だと再帰的になって結構大変 ●同一 gemは1バージョンのみの登録が基本 パッケージは名称で管理していてバージョンは管理が別なので ●gem 同士の依存関係も pkgsrc として管理 gem 自身にも依存関係記述のしくみがあるが 二重管理になっている

Slide 15

Slide 15 text

ruby gem の扱い② ●異なるパッケージが、同一の gem の 異なるバージョンを要求している場合 ➢API/ABI非互換が明らか、かつ、 共存必要な場合は別の名前で別パッケージ化 ➢gem側の依存関係記述が不明確な場合は pkgsrcの枠組みで依存関係を強制的に上書き gem側も依存関係のバージョン記載が 「最新バージョンを書いてる」「単に放置プレー状態」 といろいろなのでいろいろと難しい

Slide 16

Slide 16 text

ruby gem 依存の落とし穴 ●先程書いたように、パッケージシステム的 依存関係は gemとは独立して管理 ●しかし実行時は Gemfile 等に書かれた 依存関係がチェックされる ➔両者が不一致だと実行時エラーでハマる

Slide 17

Slide 17 text

ruby gem 依存の落とし穴 ●ubuntu 17.10 の apt の mikutter で gobject-introspection を手動で入れる 必要があったのも同様の問題 debian では直ってたけど ubuntu はずっと放置プレー ●私はとりあえず Gemfile その他を見て 手動でメンテしてます わりとめんどい ●詳しくは mikutter Redmine #1145 参照

Slide 18

Slide 18 text

totoridipjp gem問題 ●mikutter 3.3 で pluggaloid gem 導入 ●それと同時に totoridipjp gem の発生 ハイテンションになっていたとしぁさんを思い出す ●photo_support plugin が標準で totoridipjp gem を要求 ●totoridipjp gem が入っていないと mikutter も起動しないという課題が発生 ●plugin が要求する gem なので vendor以下 にも添付されていないという問題

Slide 19

Slide 19 text

totori.dip.jp とは

Slide 20

Slide 20 text

debian totoridipjp 対応

Slide 21

Slide 21 text

debian totoridipjp 対応

Slide 22

Slide 22 text

( ﾟдﾟ)

Slide 23

Slide 23 text

debian totoridipjp 頓挫

Slide 24

Slide 24 text

debian totoridipjp 現状

Slide 25

Slide 25 text

張本人による述懐

Slide 26

Slide 26 text

pkgsrc での totoridipjp ●debianで入るなら…と思ってたけど挫折

Slide 27

Slide 27 text

ちなみに AUR では

Slide 28

Slide 28 text

さらに Fedora では

Slide 29

Slide 29 text

／(^o^)＼

Slide 30

Slide 30 text

pkgsrc独自パッチ ●基本は upstream にフィードバックすべき ●ただし基準はわりとアバウトな感じ ✔セキュリティ修正を緊急で当てる場合 ✔重大バグで次リリースを待てない場合 ✔マイナーOS対応を拒否られた場合 ?機能バグでも次のリリースが待てない ?オレが欲しい機能を追加したい

Slide 31

Slide 31 text

net/mikutter/patches ●以下のようなのも入れてたり ✔masterへのマージが忘れられてるもの Twitpicの https 対応とか ✔チケット上で保留になっているが 手元ではそれなりに動いているもの delayer-deferred 2.x 対応とか 自分では直った気分になってて、 パッチが残っているのに気づいて 忘れられているのを思い出してたり……

Slide 32

Slide 32 text

pkgsrcコミットログ問題 ●「upstreamのchangelogをログに書け」 という謎のルールがある ●「URLリンクでは時が経つと消えるから」 という理論らしい ●しかし、 upstream のドキュメントが 英語でない場合のルールは無いっぽい？ ●“No English changelog” とだけ書いて 変更点を書かなくても怒られたことはない

Slide 33

Slide 33 text

pkgsrc mikutter ログ ●伝統的(?)に、としぁさんの書いている リリースブログの変更点が、なんとなく 英訳されてログに書かれている ✗これにかかる時間のせいでリリース競争に負けがち

Slide 34

Slide 34 text

➢必要な各種 gemのパッケージ化と それらの依存関係の管理がメイン ➢オレオレ修正パッチを入れられる のはある意味役得というところ？ ➢としぁ語リリースノート英訳は それなりに気合が必要ですが l10nの勉強になります まとめ