rpmで問題が起きたのでまとめておく．あと英語で書くと日本の人が読んでくれないのでまず日本語で…
現在のtd-agentは1.1.19だが，2.0.0と1.2.0があった場合，yum updateでは2.0.0が入ってしまう．これでは，Rubyのバージョンが変わった場合などはgemの再インストールが必要で，単なるアップデートでは起動出来なくなるという問題がある(chefとか使っていれば多分防ぐことは出来るが強制することは出来ない)．
もしtd-agentのままでいく場合，いつかは強制的に非互換のバージョンアップをする必要がある．
ユーザがとりあえず今のままで良いからFluentdとか同梱されているgemだけのバージョンが上がった安定したtd-agentが欲しいと思った時，この方法ではそのアプローチは取れない． そのためこの方法では，新しいRubyでtd-agentを試したいという場合に，対応するのが難しい．
td-agentが入っている状態でtd-agent2をインストールすると，上手く動かないという問題．debでは起きていない． 原因は，rpmのspecでのfilesのミスマッチにより，/etc/init.d/td-agentが消えてしまう．td-agent2はomnibus-rubyで作られているが，omnibus-rubyが利用しているfpmの影響で，specファイルは直接弄ることが出来ない．
https://github.com/jordansissel/fpm/blob/master/templates/rpm.erb
%installとかもこちらで指定出来ないので，対応するのが難しい．
Twitterでのやりとりを含めいくつか案がある
- td-agent2ではファイル名などをtd-agent2にする．/etc/init.d/td-agentでtd-agentと被っているのが問題なので，/etc/init.d/td-agent2などにする
- yum remove td-agent; yum install td-agent2と順序を指定する．
- fpmのspecをなんとかして頑張って上書きする
- 誰かが超神的な回避策を思いつく
1.はユーザにとってどうなのかという問題．curlとかのコマンドがそうだけど，メジャーバージョンアップしてもコマンドそのものが変わらないパッケージはそれなりにあり，td-agentもそっちの方が嬉しいのかどうか
2.は，これは今回specファイルに違いがあることが原因で，今後のメジャーバージョンアップでは問題は起きないと思われるので，今回だけ我慢してもらう案 chef-td-agentとかで上手く対応出来るのかどうかは調べる必要がある
3.は独自のアドホックなコードがかなり入り込むので，あまりやりたいくない．
今回の問題はrpmだけで起きている感じなので，できればdebとかに影響は与えたくないとは思っている．あと，今回選んだアプローチは後々td-agent3とかにも影響があると思われる．
MariaDBやCDHやHDPやElasticsearchを調べると，パッケージ名は変えずにbaseurlなどのパスにバージョンを含めるアプローチを取っているようだ(from @shun0102)． この方法を使えば，td-agent2のようにパッケージ名を分けなくても，td-agentの中でメジャーバージョンをあげつつ，単一のパッケージでリリースを続けることが出来る． が，/etc/init.d/td-agent問題は解決していない