hito による投稿:

jedipunkz による投稿:

レポジトリを参照するインストール対象サーバの /etc/apt/preferences.d/foo に

    Package: *
    Pin: release o=foo
    Pin-Priority: 1001

本来ならこれで行けるはずなのですが、12.04での挙動の変化を仮定する前に、

apt-cache policy ${レポジトリに置いたパッケージ}

の結果を確認してみて頂けるでしょうか？
これにより、「単にレポジトリに12.04対応パッケージがない」といった可能性を潰すことができます。

結果がこちらになります。

apt-cache policy qemu-kvm
qemu-kvm:
  Installed: 1.0+noroms-0ubuntu13
  Candidate: 1.0+noroms-0ubuntu13
  Version table:
*** 1.0+noroms-0ubuntu13 0
        500 http://jp.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
       1001 http://10.240.1.61/repo/ ubuntu1204/ Packages
        100 /var/lib/dpkg/status

独自レポジトリの pin priority が 1001 になっているように見えます。ただ順番が上から2番目に
なっているのが気になっています。実際、一番上の jp.archive.ubuntu.com からファイルを取得
してしまいました。

また、独自レポジトリ上の Packages.gz と Release ファイルは独自レポジトリ HTTP サーバの
ログから、取得されているのが判りました。

独自レポジトリ上のパッケージバージョンは、jp.archive.ubuntu.com 上のパッケージバージョンと
全く同じ状態です。これが原因で jp.archive.ubuntu.com から取得してしまっているのでしょうか？
だとすると、少し意図していない動きをしています。

hito による投稿:

jedipunkz による投稿:

独自レポジトリ上のパッケージバージョンは、jp.archive.ubuntu.com 上のパッケージバージョンと
全く同じ状態です。これが原因で jp.archive.ubuntu.com から取得してしまっているのでしょうか？
だとすると、少し意図していない動きをしています。

意図には反するかもしれませんが、これは「書いたとおりに動いている」状態だと思います。
独自パッケージに公式パッケージと同じバージョン文字列をつけるのは自殺行為なので、まずこれを脱却した方がいいです。

hito さん、コメントありがとうございます。

動作確認出来ました。10.04 LTS の際は確かに独自のバージョンを付けていたため、独自レポジトリから
取得出来ていたようです。今回はテストのためだったので、同じバージョン情報をもったパッケージを独自
レポジトリに投入し、今回の現象に陥っていました。

公式レポジトリのスナップショット的レポジトリとして独自レポジトリを運用したいと思っておりました。
が、リビルドが必要無いパッケージについても、別バージョンを付けるために、リビルド作業は実施した
ほうが良いということですね。もしくは、同じバージョンのパッケージに差異がないと管理者の私が判断
出来るのであれば、公式レポジトリからパッケージを取得しに行っても "良し" とする、という運用ポリシ
にするのもありかとは、思っています。

引き続き調査して、開発者の意図をもう少し探ってみようと思います。

色々教えていただいてありがとう御座います！

調査するつもりでしたが、hito さんの回答で疑問と問題点がクリアになりました。

hito による投稿:

pining等、apt_preferencesでパッケージバージョンを制御できますが、これにはそもそも、
以下の原則が含まれています。

　A) リビルドが必要ないパッケージ＝バージョン文字列が公式と同じになる。結果として
　　 pinningの優先順位上どちらがダウンロードされても良い。
　B) リビルドのみ必要なもの＝nochange rebuildのためにバージョン文字列を変更する
　C) 独自に修正を加えたパッケージ＝バージョン文字列を変更する

今回だと、A) の場合においても（速度や帯域面から？）独自レポジトリを優先してほしい、
ということが課題なのだと思うのですが、pinningの原則からして機能しません。

私の行いたい運用は A) のパターンで実践出来ると理解しました。特定のタイミングでのパッケージ
バージョン組み合わせが維持できれば OK でした。バージョンが同じであれば中身も同じ
という大前提の元、公式レポジトリからパッケージを取得するのは、私にとって問題なし
です。

また、公式レポジトリのパッケージがバージョンアップした場合、pin priority = 1001
な独自レポジトリのパッケージバージョンが優先される (1001 : ダウングレードしてでも
対象レポジトリを参照する) ため、バージョンが維持出来るはずです。これも私にとって
好都合であり、問題なしです。

hito による投稿:

もしレポジトリそのもののダウンロード速度等の有利・不利が原因であれば、意味のない
nochange rebuildを行うべきではなく、なんらかの別の方法を検討すべきです（たぶん
apt-proxyやSquidでなんとかすべきで、この部分についてはpinningするのは変）。

また、「同じバージョンのパッケージに差異がないと判断する」のは管理者や運用ポリシのレイヤ
ではなく、パッケージ管理の前提条件であるように思います。「中身は違うけど同じバージョン
文字列のパッケージを許す」というのは、危険度としては「全員rootで作業する」と同程度に危険
ですし、なにより一貫性を保つことが非常に困難になります。

"中身が異なる可能性があるのにバージョンが異なること" の危険性について理解しました。
独自レポジトリを利用するのが私以外であれば、大きな問題に繋がる。また、これは
"利用するのが私だけ" というポリシを前提に、"Debian/Ubuntu のパッケージ管理ポリシ・
関係" を崩すべきではない、ことも理解しました。

hito さん、ありがとうございました。