>目前安装的软件包及其版本
>哪些包固定在什么版本
>从哪个源(如在/etc/apt/sources.list中)安装它们
>它们是直接安装还是自动安装为不同软件包的依赖项
>“未知的未知数”：即我不知道我应该跟踪的东西,但在试图弄清楚为什么某些东西不起作用时哪些可能很重要
简而言之,我想尽可能多地保留aptitude数据库.最好的方法是什么？如果结果记录易于阅读,那将是很好的,尽管这不是真正必要的.如果可以通过像git这样的SCM工具轻松实现版本,那将会特别好.
有一个superuser question可以部分回答这个问题,但它只提供当前安装的软件包列表.
更新
根据@ ptman的回答,我确定了以下内容：
> @ ptman的最后一个建议,即备份/ etc / apt和/ var / lib / …,将完成aptitude-create-state-bundle的子集.
> apt-cache策略似乎只是提供优先级信息,所以我需要更全面的东西; aptitude-create-state-bundle似乎是票.但是,有一些方法可以分析bundle以获取apt-cache策略提供的信息.
我已经开始了一个git repo(使用setgitperms.perl hook util),其中包含aptitude-create-state-bundle的提取内容,例如我做的
sudo aptitude-create-state-bundle --force-gzip /dev/stdout | sudo tar xzv
在运行git add之前创建目录内容. &安培;&安培; git add -u ..它有点慢,因为它压缩和解压缩所有内容,我可能会将其更改为只使用–print-inputs选项获取文件列表,然后将这些文件复制或硬链接到git repo中.
这种方法非常有效：在运行git gc -aggressive之后,我得到了一个.git目录,它的大小是原始tarball的2/3.这是在安装puppet及其依赖项后记录状态的第二次提交之后完成的.只需查看差异就可以很容易地看到改变了什么,这是一种很好的方法,可以找出执行操作时能力实际上做了什么.我认为有一些方法可以在apt本身中放置钩子(àlaetckeeper),所以我最终可能会使用该工具来保持每个apt操作更新repo.
一个小问题是,即使启用了setgitperms挂钩,该系统也不会记录时间戳.所以我在我的预提交钩子中添加了第二个命令,将一个长目录列表转储到repo根目录中名为.ls的文件中：
find * | xargs -d \\n ls -ld >.ls
我不确定这是否真的有必要,我只是在aptitude-run-state-bundle以某种相关的方式使用时间戳时才这样做.谁知道这是真的吗？即使这样,似乎也不太必要,因为签出文件的时间戳始终至少与提交时这些文件的原始时间戳一样新.
我将继续这样做,至少在我有机会弄清楚木偶做什么以及如何使用它之前.
更新2
我一直在使用这个系统,但它看起来确实有点笨拙,因为.git repo正在快速增长.在12次提交之后,.git目录(在使用git gc -aggressive进行压缩之后)的大小从初始大小(IIRC)15-20 MB增加到大约60 MB.
似乎大部分的批量似乎是由于两个大(~15MB)二进制文件中的差异,我想知道这些文件是否是保存系统打包状态所必需的.那些文件是：
var/cache/apt/pkgcache.bin var/cache/apt/srcpkgcache.bin
如果这些文件不存在于tarball中,是否可以使用aptitude-run-state-bundle恢复repo？是否可以将当前系统版本添加到tarball中以使aptitude-run-state-bundle能够使用该tarball(当然,假设当前系统版本没有损坏)？
dpkg --get-selections
aptitude-create-state-bundle
dpkg -l
dpkg -l |tail -n +6 | awk '{ print $2 }' | xargs apt-cache policy
备份/ etc / apt和/ var / lib / {apt,dpkg,aptitude}.
