debianのパッケージングができるようになった夏
この記事はdebianのパッケージングができるようになった夏がオリジナルです。 OSS Gateのサイトにあわせてマークアップを一部修正してあります。
こんにちは、しぶちゃりです。
僕は今年の夏にOSSオンボーディングという取り組みに参加し、debianのパッケージングを行いました。
この記事はその参加記録です。1人でもやってみたい人が増えればいいなと思い記事を執筆させていただきます。
応募した動機
OSSオンボーディングを知ったきっかけは、あるDiscordのチャンネルでdebianのイベントが開催されるらしいということを聞いたことが始まりでした。
その時の心境としては、最近はAPIの開発が多かったことからも全く関心がなかった技術分野を知りたいという気持ちでした。
その後実際に応募要項や今までdockerのimageとして用いるくらいであったdebianがどのようなものか調べていくうちに興味が湧き応募しました。
OSSオンボーディングの経験はとても楽しかったため、自分の多くのものに関心を持てる性格がプラスに働いたと感じます。
取り組んだこと
今回はdebianのパッケージングを実際にメンターの方と一緒に進めていくというコースに応募しました。
その際にパッケージングしてみたいものがあるかという項目が存在していたため、slack-termというコンソール上でslackを操作できるツールのパッケージングを希望しました。
このツールを選定した理由としては、普段自分自身がGoを書いていることが多いため、コードをいじることがあっても障壁を感じず、何かしらプログラムのランタイムエラーやコンパイルエラーを解決しなくてはいけないケースが生じてもdebianのことに集中できると仮定したからです。
また、インターンでSlackのAPIを触る経験があり、慣れ親しんだAPIであったため、Slack API関係の問題が生じた場合も、同様にdebianに集中できるということもありました。
実際に応募した際のページがこちらです。
その後、実際に受理され、面談を経たのちにスタートしました。
実際にパッケージングを行ってみると、普段の開発とは異なる苦労が存在しました。
例えば、slack-termをパッケージングするにあたり、slack-termが依存してるライブラリを調査することからスタートしました。
その結果
-
fuzzy-search
-
notificator
-
slack-go
-
term-ui
とい4つの依存が存在しました。
そのため、debianで動作するためにも先に上記の4つをパッケージングする必要があり、今回のOSSオンボーディングは最大限これらをパッケージングすることとなりました。
コードベースの依存性や、ライブラリの依存性などは以前から気にしていた部分ですが、動作する前提での依存性の話をする経験が多かった僕にはこの経験がとても楽しいと同時に多くの動作する環境を整備しているエンジニアの凄さを改めて感じました。
OSSオンボーディングの中ではfuzzy-searchとnotificatorのパッケージングを行いました。
このパッケージングにあたり、debianの環境で実際に動かすためにパッケージング対象のビルドテストを行ったり、有償ではなくコミュニティとして動いているdebianならではのライセンス問題や、debianのお作法として存在するフォーマットに合わせて、同様にdebian固有のファイル操作やコマンドを実行するなど多くの経験を積みました。
実際にOSSオンボーディング後もパッケージングは行っており、この時の経験と足りない部分はメンターであったKentaro Hayashiさんに質問するなどして活動を続けています。
よかったこと
まず、今まで触れたことがなかった領域に触れることができた経験が何よりも大きいです。
今まで僕はOSSへのコントリビュートや、自身でライブラリを作成する際にも、前提として動作することが当然であると考え開発していました。
もちろん、この考え方にある種の反論はあれど言語固有のツールを使う際には暗黙的に当然である考え方であると思います。
ここで感じたことは自身のライブラリがどこでどのように活用されるかわからない(OSSであり、誰でも介入できる)ので、多くの人がメンテナンスがしやすく、かつ動作をしやすい状況を維持するかを考え始めました。
実際に今僕は作成しているTwitter v2 APIのライブラリはテストコードで用いている3rdパッケージを除き、全てGoの標準パッケージで構成されています。
気になったこと
今回僕がパッケージングしたコードはGitLabにアップロードされており、実際にパッケージとして公開される前にも、mentors.debian.netというところにpendingとして挙げられacceptされることで公開される方式を取りました。
これはdebianでの権限などもあり、必ずしもこの方針を取る必要があるかは各々によるとは思いますが、初めてパッケージングする人にとってはセーフティーな環境となっています。
その反面、debianのお作法に則り統一するために普段用いるような(GitHub)などは用いていません。
仮にこの部分で面倒などの障壁を感じ、僕のようにメンターに聞ける環境がないばかりに諦めている方がいれば、とても惜しいなと思いました。
またdebianのパッケージングなどの情報はKentaro Hayashiさんの所属する企業である、Clear Codeの記事を除くとほとんど日本語で書かれた記事はなく、デザイン的もお世辞にも見やすいとは言えません。
これらのことが障壁となり関心があるが離れてしまった人がいる可能性は充分あると思うので、僕のようにdebianのパッケージングを楽しめる環境を作っていければいいなということが直近のdebianコミュニティを盛り上げることとしてやってみたいと構想しているミッションです。
応募前の想定と実際の内容とのギャップ
ここに関してはパッケージングをする上での苦労以外を除くと、僕の場合は大きな差分はありませんでした。
またこの苦労は望んでいたものなのでとても楽しかったです。
もしこの記事を読んで同じようにパッケージングをやってみたいという方がいましたら、情報の多くは英語で書いているものを読む方が情報が手に入るため、翻訳サービスを用いて読むなどの方法でも構いませんが、英語に心理的なハードルを設けていない方の方が向いているかと思いました。
今後の新人・先輩・運営へのコメント
Kentaro Hayashiさんをはじめとし、Clear Codeの皆様の暖かい気持ちとこちらの小さな疑問にも丁寧に答えていただける環境があったからこそ、OSSオンボーディングをとてもいい思い出として、楽しめたと思います。
そのため、今でもdebianのパッケージングをしようと考えていることは間違いなくこのおかげです。
改めて、とても楽しくいい経験を積ませていただきありがとうございました。今後ともよろしくお願いします。
もし、この記事を読み少しでも関心が湧いた方はぜひ僕のTwitterにDMしてください。
答えられる範囲であれば回答します。
最後までお読みいただきありがとうございました。