FATファイルシステム上のファイルを置き換えるdpkg

dpkg（および最終的にapt-getなどのように）パッケージをアップグレードまたは再インストールすると、ファイルを置き換える前にファイルへのハードリンクを作成して既存のファイルをバックアップします。こうすると、アンパックが失敗した場合、既存のファイルを簡単に戻すことができます。Bad Things™の発生からオペレーティングシステムを保護するので、それは素晴らしいことです。

ただし、ファイルシステムがハードリンクをサポートしている場合にのみ機能します。FATファイルシステムなど、すべてのファイルシステムがそうするわけではありません。

私は特定の組み込みARMプラットフォーム用のDebianのディストリビューションに取り組んでいます。ブート環境では、特定のファイル（カーネルが含まれています）がFATファイルシステム上にある必要があります。

カーネルパッケージ（またはそのFATパーティションにファイルがある他のパッケージ）をアップグレードしようとすると、インストールは次のように失敗します。

dpkg: error processing archive linux-image3.18.11+_3.18.11.2.armadillian_armhf.deb (--install):
 unable to make backup link of `./boot/vmlinuz-3.18.11+' before installing new version: Operation not permitted

そして、アップグレード全体が失敗します。

私はウェブを探しましたが、特定のアップグレードを行うときに特定の問題を抱えている特定の人だけを見つけることができます。その答えは通常「/boot/vmlinuz-3.18.11+を削除して再試行する」です。その特定の問題を修正します。

しかし、それは私にとっての答えではありません。私はOSユーザーではなくOSディストリビューターなので、アップグレードを行う前にエンドユーザーが手動でカーネルファイルを削除する必要のない、これを修正する方法が必要です。/ bootのファイル（または、アップグレード操作が多少遅くなりますが、気にするすべてのファイル）の「ハードリンクではなくコピー」をdpkgに伝える方法、または「ハードリンクが失敗した場合、文句を言わないで、代わりにコピーするだけです。」

--force-unsafe-ioやのような--force-allフラグを試してみましたdpkgが、何も効果がありません。

表示されている動作archives.cは、dpkgソースの行1030（バージョン1.18.1の場合）に実装されています。

debug(dbg_eachfiledetail, "tarobject nondirectory, 'link' backup");
if (link(fnamevb.buf,fnametmpvb.buf))
  ohshite(_("unable to make backup link of '%.255s' before installing new version"),
          ti->name);

1003行目以降の名前変更動作にフォールバックすることで、リンク障害を処理できるように思えます。次のようなもの（これはテストされていません）：

debug(dbg_eachfiledetail, "tarobject nondirectory, 'link' backup");
if (link(fnamevb.buf,fnametmpvb.buf)) {
  debug(dbg_eachfiledetail,"link failed, nonatomic");
  nifd->namenode->flags |= fnnf_no_atomic_overwrite;
  if (rename(fnamevb.buf,fnametmpvb.buf))
    ohshite(_("unable to move aside '%.255s' to install new version"),
            ti->name);
}

私はないんだけどdpkg...しかし、専門家（そして、すでに利用可能なオプションはありませんdpkg、この動作を提供するには。）