Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.3.1 2016-07-01T12:33:02Z 2016-07-01T12:33:02Z David Kalnischkies david@kalnischkies.de 2016-07-01T12:00:47Z urn:sha1:cb9ac09bd6a36e73c2dce1d529acde6e4d15e32d As the volatile sources are parsed last they were sorted behind the dpkg/status file and hence are treated as a downgrade, which isn't really what you want to happen as from a user POV its an upgrade. 2016-03-06T13:57:41Z Julian Andres Klode jak@debian.org 2016-03-06T13:44:53Z urn:sha1:9e7f83533665c03b52dff5809e7ebd93928ea445 If an iterator or a stringview has multiple dynamic objects registered with it, it may be remapped twice. Prevent that by noting which iterators/views we have seen and not remapping one if we have already seen it. We most likely do not have any instance of multiple dynamics on a single object, but let's play safe - the overhead is not high. 2016-01-26T23:15:12Z David Kalnischkies david@kalnischkies.de 2016-01-26T23:15:12Z urn:sha1:a133f79c8766aee5b7d7811285e60b3d311d8473 It is a bit academic to support values which aren't big enough to fit even the hashtables without resizing, but cleaning up ensures that we do the right thing (aka not segfaulting) even if something goes wrong in these deep layers. You still can't have very very small values through… Git-Dch: Ignore 2016-01-26T22:18:05Z David Kalnischkies david@kalnischkies.de 2016-01-26T22:18:05Z urn:sha1:8efd5947bf7de0fc3db51b4871bcf3522018761d Part of hidden classes, so conversion is abi-free. Git-Dch: Ignore 2016-01-25T17:15:44Z David Kalnischkies david@kalnischkies.de 2016-01-21T22:22:00Z urn:sha1:a249b3e6fd798935a02b769149c9791a6fa6ef16 build-dep was implemented by parsing the build-dependencies of a package and figuring out which packages to install/remove based on this. That means that for the first level of dependencies build-dep was implementing its very own resolver with all the benefits (aka: bugs) this gives us for not using the existing resolver for all levels. Making this work involves generating a dummy binary package with fitting Depends and Conflicts and as we can't create them out of thin air the cache generation needs to be involved so we end up writing a Packages file which we want to parse – after we have parsed the other Packages files already. With .dsc/.deb files we could add them before we started parsing anything. With a bit of care we can avoid generating too much data we have to throw away again (as many parts assume that e.g. the count of packages doesn't change midair), so that on a speed front there shouldn't be much of a difference, but output can be slightly confusing as if we have a completely valid cache on disk the "Reading package lists... Done" is printed two times – but apt is pretty quick about it in that case. Closes: #137560, #444930, #489911, #583914, #728317, #812173 2016-01-25T17:15:44Z David Kalnischkies david@kalnischkies.de 2016-01-22T01:00:42Z urn:sha1:074564d40c21cb063bf327e9151a4e24cd9534b5 Proper debian packages do not contain ':' in the package name, so for real packages this is a non-issue, but apt itself frequently makes use of packages with such an illegal name for internal proposes. Git-Dch: Ignore 2016-01-25T17:15:44Z David Kalnischkies david@kalnischkies.de 2016-01-19T23:09:36Z urn:sha1:530302ef25d14bd7577f18cf98c2fa868c3c1dd3 To resolve dependencies like "pkg:arch" we create a package with the name "pkg:arch" and the architecture "any". We create these packages only if a dependency needs it as these kind of dependencies aren't that common. This commit ensured that in the even this architecture specific dependency is the only relation this package has we still create the underlying package to have them available in provides resolution. 2016-01-23T14:40:17Z Julian Andres Klode jak@debian.org 2016-01-23T14:37:59Z urn:sha1:8ee09b58e9f061cf5296c54680e2b3386f83ff04 I only looked at parameters in the previous commit, which was not enough: One place also generated local string views. In this case, we only need to make ArchA dynamic, as NameA is not used after the FindPkg() call. Gbp-Dch: ignore 2016-01-23T14:20:52Z Julian Andres Klode jak@debian.org 2016-01-23T12:15:31Z urn:sha1:7dd0c2eb45874d3df9a9ee2034501659548a1b97 It turns out that StringViews might need to be remapped in some places because they come from the cache. For example, some sites pass a Ver.VerStr() to NewProvides(). Such a StringView would become invalid during the duration of the call if the cache is remapped, causing the program to die with a segmentation fault. We can take care of those issues by remapping string views in the same way we remap all the iterators. String views are only remapped if they point into the cache though, this allows us to write more generic code on the callee site without having to check whether the view points into the cache or not. That's not as efficient as possible, but the overhead does not appear to be measurable. Closes: #812251 2016-01-23T14:13:04Z Julian Andres Klode jak@debian.org 2016-01-23T14:02:48Z urn:sha1:19819ac58a420275e0ae9aa7e2a34c72cba8af5e This allows us to check if a value to be remapped was inside the cache or not, which will become useful at a later point. Gbp-Dch: ignore