diff options
author | David Kalnischkies <david@kalnischkies.de> | 2015-06-12 02:08:53 +0200 |
---|---|---|
committer | David Kalnischkies <david@kalnischkies.de> | 2015-06-12 16:33:37 +0200 |
commit | b07aeb1a6e24825e534167a737043441e871de9f (patch) | |
tree | b47b5bced3f6352e2cdd6cfa550e351e8cd6ebab /COMPILING | |
parent | 8881b11eacd735148d087c8c0f53827cb537b582 (diff) |
store Release files data in the Cache
We used to read the Release file for each Packages file and store the
data in the PackageFile struct even through potentially many Packages
(and Translation-*) files could use the same data. The point of the
exercise isn't the duplicated data through. Having the Release files as
first-class citizens in the Cache allows us to properly track their
state as well as allows us to use the information also for files which
aren't in the cache, but where we know to which Release file they
belong (Sources are an example for this).
This modifies the pkgCache structs, especially the PackagesFile struct
which depending on how libapt users access the data in these structs can
mean huge breakage or no visible change. As a single data point:
aptitude seems to be fine with this. Even if there is breakage it is
trivial to fix in a backportable way while avoiding breakage for
everyone would be a huge pain for us.
Note that not all PackageFile structs have a corresponding ReleaseFile.
In particular the dpkg/status file as well as *.deb files have not. As
these have only a Archive property need, the Component property takes
over this duty and the ReleaseFile remains zero. This is also the reason
why it isn't needed nor particularily recommended to change from
PackagesFile to ReleaseFile blindly. Sticking with the earlier is
usually the better option.
Diffstat (limited to 'COMPILING')
0 files changed, 0 insertions, 0 deletions