apt/apt-pkg/versionmatch.cc, branch 1.3 Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.3 2015-08-10T15:25:25Z simplify Origin matchmaking for status files 2015-08-10T15:25:25Z David Kalnischkies david@kalnischkies.de 2015-06-17T17:22:13Z urn:sha1:ddb286525d196b53683533648425c5c8f5288839 The old check is overly complicated nowadays as we have a pretty defining difference between packages from a Packages files coming from with a Release file (even if the file itself doesn't exist) and packages coming from the dpkg.status or directly out of *.deb's as these have no associated Release file. Git-Dch: Ignore versionmatch: Extract version match checking out of Find() 2015-08-10T09:19:11Z Julian Andres Klode jak@debian.org 2015-08-10T09:19:11Z urn:sha1:5bfd306ee16fd1be012dd2cd01ae52ff4179176a Refactor version matching to allow us to check if a version matches a pin. This will aid the per-version pinning implementation. store Release files data in the Cache 2015-06-12T14:33:37Z David Kalnischkies david@kalnischkies.de 2015-06-12T00:08:53Z urn:sha1:b07aeb1a6e24825e534167a737043441e871de9f 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. cleanup headers and especially #includes everywhere 2014-03-13T12:58:45Z David Kalnischkies david@kalnischkies.de 2014-03-05T21:11:25Z urn:sha1:453b82a388013e522b3a1b9fcd6ed0810dab1f4f Beside being a bit cleaner it hopefully also resolves oddball problems I have with high levels of parallel jobs. Git-Dch: Ignore Reported-By: iwyu (include-what-you-use) various simple changes to fix cppcheck warnings 2013-03-10T11:24:13Z David Kalnischkies kalnischkies@gmail.com 2013-03-10T11:24:13Z urn:sha1:69c2ecbdc937e3c73fe67d3c9bce12a80d3ec7ec do not pollute namespace in the headers with using (Closes: #500198) 2011-09-19T11:31:29Z David Kalnischkies kalnischkies@gmail.com 2011-09-19T11:31:29Z urn:sha1:8f3ba4e8708cb72be19dacc2af4f601ee5fea292 merge with debian/experimental 2011-09-13T15:52:22Z David Kalnischkies kalnischkies@gmail.com 2011-09-13T15:52:22Z urn:sha1:74b220028595342028e3309002e4ec359af328f9 reorder includes: add <config.h> if needed and include it at first 2011-09-13T08:09:00Z David Kalnischkies kalnischkies@gmail.com 2011-09-13T08:09:00Z urn:sha1:ea54214002c09eeb4dd498d97a564471ec9993c5 cppcheck complains about some possible speed improvements which could be 2011-08-11T18:53:28Z David Kalnischkies kalnischkies@gmail.com 2011-08-11T18:53:28Z urn:sha1:f7f0d6c7560a8f71707e7852a512469147aa9f84 done on the mirco-optimazation level, so lets fix them: (performance) Possible inefficient checking for emptiness. (performance) Prefer prefix ++/-- operators for non-primitive types. check for length of Data to avoid the validness of 2010-09-02T13:19:51Z David Kalnischkies kalnischkies@gmail.com 2010-09-02T13:19:51Z urn:sha1:99aa69c74f27a70d585510b817561fbf20ac7fb5 Pin: origin " (no error displayed). We already know in this method that Data is at least one char long, so we avoid the length counting as long as the string doesn't start with "