Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.3.1 2016-08-10T21:51:35Z 2016-08-10T21:51:35Z David Kalnischkies david@kalnischkies.de 2016-07-28T07:13:24Z urn:sha1:28557f94578602f9ce0011501a2259bd98ab0688 With b4450f1dd6bca537e60406b2383ab154a3e1485f we dropped what we calculated here later on and now that we don't need it in the meantime either we can just skip the busy work by default and expect dpkg to do the right thing dropping also our little "last explicit configures" removal trick introduced in b4450f1dd6bca537e60406b2383ab154a3e1485f. This enables the last of a bunch of previously experimental options, some of them existing still, but are very special and hence not really worth documenting anymore (especially as it would need to be rewritten now entirely) which is why the documentation is nearly completely dropped. The order of configuration stanzas in the simulation code changes slightly as it isn't concerning itself with finding the 'right' order, but any order is valid anyhow as long as the entire set happens in the same call. 2016-08-10T21:51:34Z David Kalnischkies david@kalnischkies.de 2016-07-28T09:43:36Z urn:sha1:4326680d2ed23d597f45ca8872a7054368560acc If a planner lets actions to be figured out by dpkg in pending calls these actions aren't mentioned in a simulation. While that might be a good thing for debugging, it would be a change in behavior and especially if a planner avoids explicit removals could be confusing for users. As such we perform the same 'trick' as in the dpkg implementation by performing explicitly what would be done by the pending calls. To save us some work and avoid desyncs we perform a layer violation by using deb/ code in the generic simulation – and further we perform ugly dynamic_cast to avoid breaking the ABI for nothing; aptitude is the only other user of the simulation class according to codesearch.d.n and for that our little trick works. It just isn't working if you happen to extend pkgSimulate or otherwise manage to call the protected Go methods directly – which isn't very realistic/practical. 2016-06-29T10:17:41Z David Kalnischkies david@kalnischkies.de 2016-06-29T07:16:53Z urn:sha1:8e99b22c31eb47d0422e9a69e83dc99bb315ded8 Julian noticed on IRC that I fall victim to a lovely false friend by calling referring to a 'planer' all the time even through these are machines to e.g. remove splinters from woodwork ("make stuff plane"). The term I meant is written in german in this way (= with a single n) but in english there are two, aka: 'planner'. As that is unreleased code switching all instances without any transitional provisions. Also the reason why its skipped in changelog. Thanks: Julian Andres Klode Gbp-Dch: Ignore 2016-06-27T09:57:13Z David Kalnischkies david@kalnischkies.de 2016-06-26T11:20:19Z urn:sha1:b4f91d4d150a0d9bcc77563abbc03d28da2ff4e3 In 385d9f2f23057bc5808b5e013e77ba16d1c94da4 I implemented the storage of scenario files based on enabling this by default for EIPP, but I implemented it first optionally for EDSP to have it independent. The reasons mentioned in the earlier commit (debugging and bugreports) obviously apply here, especially as EIPP solutions aren't user approved, nearly impossible to verify before starting the execution and at the time of error the scenario has changed already, so that reproducing the issue becomes hard(er). 2016-06-27T09:57:12Z David Kalnischkies david@kalnischkies.de 2016-06-06T15:58:00Z urn:sha1:8d1cb6da6e21302c654da3f09de3975af7e4a11f A rather special need option, but the internal planer supports this and we have a testcase for it & sometimes it is hit (as a bug through). The option itself mostly serves as a reminder for implementors that they should be careful with removes and especially temporary removes if they perform any. 2016-06-27T09:57:12Z David Kalnischkies david@kalnischkies.de 2016-06-06T13:04:42Z urn:sha1:a21aca106ce93e8a2841d4a2c7a8432f9dfc7b6d APT has 3 modes: no immediate configuration, all packages are configured immediately and its default mode of configuring essentials and pseudo-essentials immediately only. While this seems like a job of different planers at first, it might be handy to have it as an option, too, in case a planer (like apts internal one) supports different modes where the introduction of individual planers would be counter intuitive. 2016-06-27T09:57:12Z David Kalnischkies david@kalnischkies.de 2016-05-28T13:40:59Z urn:sha1:f74d99c6a78caafdc6e32d8cb135683b7154795c Testing the current implementation can benefit from being able to be feed an EIPP request and produce a fully compliant response. It is also a great test for EIPP in general. 2016-06-27T09:43:09Z David Kalnischkies david@kalnischkies.de 2016-05-14T16:07:12Z urn:sha1:7b197262212f49b3b355b1124edf2ba9adb73411 The very first step in introducing the "external installation planer protocol" (short: EIPP) as part of my GSoC2016 project. The description reads: APT-based tools like apt-get, aptitude, synaptic, … work with the user to figure out how their system should look like after they are done installing/removing packages and their dependencies. The actual installation/removal of packages is done by dpkg with the constrain that dependencies must be fulfilled at any point in time (e.g. to run maintainer scripts). Historically APT has a super micro-management approach to this task which hasn't aged that well over the years mostly ignoring changes in dpkg and growing into an unmaintainable mess hardly anyone can debug and everyone fears to touch – especially as more and more requirements are tacked onto it like handling cycles and triggers, dealing with "important" packages first, package sources on removable media, touch minimal groups to be able to interrupt the process if needed (e.g. unattended-upgrades) which not only sky-rocket complexity but also can be mutually exclusive as you e.g. can't have minimal groups and minimal trigger executions at the same time. 2016-04-28T08:08:32Z David Kalnischkies david@kalnischkies.de 2016-04-28T07:22:55Z urn:sha1:84573326f41dd09b914b8374548e7ee7c93d0439 The old prettyprinters have only access to the struct they pretty print, which isn't enough usually as we want to know for a package also a bit of state information like which version is the candidate. We therefore need to pull the DepCache into context and hence use a temporary struct which is printed instead of the iterator itself. 2016-04-13T19:33:32Z David Kalnischkies david@kalnischkies.de 2016-04-13T14:24:12Z urn:sha1:c75e60ebb6bc7a578b57e7c4e01579798bae720b Regression introduced in commit 590f1923121815b36ef889033c1c416a23cbe9a2 (2011!) causing apt to not check if Pre-Depends are satisfied before calling --configure. This managed to hide so perfectly well for years as Pre-Depends aren't that common, apt prefers upgrading these packages first and checks for satisfaction is already in SmartUnpack, so there is only a small window of oppertunity to break a pre-dependency relation (usually with an unpack). Verified by logchecking with two provided status files in the buglog. I would have liked to write a test, but I wasn't able to reach the needed complexity to get apt to fail – but the change is small and reasonable, so what could possible go wrong™, right? LP: #1569099