まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

タグ:repository

Ubuntu ベースの環境(ラズパイなども含む)にアプリケーションを追加インストールする際には apt コマンドを使います。例えばこんな感じ:
$ sudo apt install nginx
※ apt の代わりに apt-get を使うこともありますが、現在推奨されているのは apt コマンドらしいです。

このコマンドは Ubuntu システム標準のソースリポジトリにあらかじめ nginx が登録されていて、その中で具体的に必要なモジュール一式やその導入手順が参照できるようになっていることで実現しています。インストールコマンドとしては上記のたった1行のコマンドで済むようになっていますが、実際には最新バージョンがいくつで、その導入にはどのような依存モジュールのどのバージョンが必要で、現在のシステムに導入済み(インストールの必要ないもの)は何で、、といった情報が参照され、必要なモジュールだけがインストールできるようになっています。

が、たまにこのコマンドだけではインストールできないことがあります。原因はいくつかありますが、その1つが「対象アプリケーションが標準のソースリポジトリに登録されていない」場合があります。要は目的のアプリケーションをインストールする手順や依存ライブラリが標準構成のソースリポジトリには登録されていないのでインストールできない、ということになります。例えば CloudFoundry の CLI ツールである cf (アプリ名としては cf-cli)をそのまま apt コマンドでインストールしようとしても以下のようなエラーになります:
$ sudo apt install cf-cli
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package cf-cli

このように標準ソースリポジトリに登録されていないことが原因でインストールできない(が、別のソースリポジトリを登録すればよい)場合は、対象アプリケーションが登録されたリポジトリを登録しなおしてあげればインストールできるようになります。

リポジトリを登録し直す方法はアプリケーションによっても異なるのですが、例えば上述の cf-cli の場合は公式ドキュメントによると以下の手順でリポジトリを登録できるようです:
$ wget -q -O - https://packages.cloudfoundry.org/debian/cli.cloudfoundry.org.key | sudo apt-key add -

$ echo "deb https://packages.cloudfoundry.org/debian stable main" | sudo tee /etc/apt/sources.list.d/cloudfoundry-cli.list

このコマンドの最後に /etc/apt/sources.list.d/ ディレクトリ内に cloudfoundry-cli.list というファイルを作成して登録しています(apt-add-repository コマンドを使って登録する方法もありますが、その場合も同ディレクトリ内にファイルが追加されます)。

なお、このようにソースリポジトリに変化があった場合はインストール前にキャッシュ内容を更新する必要があります:
$ sudo apt update

更新後は cf-cli がインストール可能です:
$ sudo apt install cf-cli

ここまでは apt の仕組みなどにあまり詳しくなくても、インストール手順を調べながら詳しく知らずに実行していることもあると思っています。


さて、問題はここからです。自分も知らなかったのですが、このように「標準構成以外に追加登録したリポジトリ」を削除したい、つまり追加登録しなかった状態に戻すにはどのようにしたらいいでしょうか? これ、意外と情報を見つけるのが難しくて苦戦したのでした。その備忘録としての本ブログでもあります。

答は以下です。3段階の手順が必要でした(特に (2) を忘れがち)。

(1) /etc/apt/sources.list.d/ 以下に追加された該当ファイルを削除する
$ sudo rm /etc/apt/sources.list.d/cloudfoundry-cli.list

(2) 記録された該当キーを見つけて削除する
$ apt-key list

(結果の一覧から cloudfoundry-cli のキーを見つける。仮に "1234ABCD" だったとする)

$ sudo apt-key del 1234ABCD

(3) リポジトリ更新
$ sudo apt update


無事にリポジトリ情報を削除して、削除した状態で更新できました。めでたしめでたし。



【参考】
https://unix.stackexchange.com/questions/219341/how-to-apt-delete-repository



GitHub で作成してしばらく使っていたリポジトリが、当初の想定以上に盛り上がったりすると、最初に適当に付けたリポジトリ名からちゃんとした正式名称のリポジトリに変更したくなる(というか、した)、という経験をしました。その時の作業手順メモです。

まず最初の注意点として、GitHub リポジトリのリネームは GitHub サーバー側と、そのクローンを保持するローカル側の両方で行う必要があります。クローンを保持するローカルが複数ある場合は、その全てのローカル側で対応が必要になります。

今回は
 https://github.com/dotnsf/old_app.git

 https://github.com/dotnsf/new_app.git
にリネームする想定で以下を説明します。

【GitHub サーバー側】
サーバー側の変更は GitHub のリポジトリ画面内から行います。まずブラウザでリポジトリページを開き、"Settings" メニューを選択します:
2018061401


"Settings" メニューのすぐ下に "Repository name" フィールドがあり、ここに変更前のリポジトリ名(今回であれば "old_app")が入力されています:
2018061402


ここを新しいリポジトリ名称(今回であれば "new_app")に変更し、"Rename" ボタンをクリックして確定させます:
2018061403


サーバー側の変更はこれだけです。この時点で名称変更前の URL にアクセスしても自動的に新しい URL にフォワードされて、新しい名前のリポジトリが表示されます:
2018061404



【ローカル側】
クローンしたローカルリポジトリ内の .git/config ファイルを編集します:
  :
  :

[remote "origin"]
        url = https://github.com/dotnsf/new_app
        fetch = +refs/heads/*:refs/remotes/origin/*

  :
  :

[remote "origin"] 項目内の url の値を新しいリポジトリの URL に変更して保存します。ローカル側の変更もこれだけですが、複数のマシンにローカルリポジトリが存在する場合は全てのローカルリポジトリを変更します。



ここまでの作業でサーバー側&リモート側ともリポジトリのリネーム作業が完了しました。当然ですが、中身は変わってない(リネーム前のまま)ので、改めてリネーム後に変更が必要なファイル(README.md とか)を更新してください:
2018061405


 

このページのトップヘ