Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.4.4 2017-03-19T14:08:08Z 2017-03-19T14:08:08Z David Kalnischkies david@kalnischkies.de 2017-03-19T14:08:08Z urn:sha1:c89b22c285d6c4a3cb64689ff26e84af4d1477f2 We are in a dilemma here: The regression of sorts was introduced in 2013 with commit d8a8f9d7f0 allowing pkg modifiers for the upgrade commands. That calls the autoremover as a sideeffect through and with it comes the option to remove the garbage packages in these commands (similar to aptitude). Having the option on the commandline is no problem – people aren't going to request what they don't want (or so I hope), but the documentation explicitly states that this option only effects install/remove and mentions a config knob users might use and expect to not suddenly apply (especially without documentation) to more commands. Just reverting the commit is out of question, completely ignoring the option breaks the workflow of every user who happened to use --autoremove on the commandline for upgrade and expects that to work given that it was accepted and worked in a stable release. Changing the documentation to reflect reality while perhaps the simplest and cleanest option contradicts freeze and is a surprising change we tend to avoid like the plague while just leaving it be confuses all users who end up believing the documentation even if was different in the last 3 years. So what we do is a tricky compromise: The configuration option if read from a file does apply only for install/remove as documented, while if the option is encountered on the commandline it is accepted and applies to the upgrade which should make 99% of the users happy. The rest has to wait for us to figure out for buster how to get that documented and implemented in a saner way. Closes: #855891 2017-01-19T14:59:38Z David Kalnischkies david@kalnischkies.de 2017-01-19T14:14:19Z urn:sha1:93cff633a830e222693fc0f3d78e6e534d1126ee Most of them in (old) code comments. The two instances of user visible string changes the po files of the manpages are fixed up as well. Gbp-Dch: Ignore Reported-By: spellintian 2017-01-19T10:50:41Z David Kalnischkies david@kalnischkies.de 2017-01-19T10:50:41Z urn:sha1:25a14d4ccfceb2698edce01092bc6a1dbe9fb217 Normal cows moo every time they feel like it and it might be a "moo", "moo!" or "moo?". This is completely unacceptable behaviour in our super cow through as as a superior being it has to show its superiority over the common cows and the meager easter eggs by being fully reproducible! The second version of Chris' patch is modified to include an array of tests for this feature – which doubles as explanation for some of the moo lines by giving more exact dates – and falling back to current time if the environment is invalid + passing time around instead of having an invalid environment be an unrecoverable error (aka: Guru Meditation) as that is more inline with how apt usually behaves: The wisdom of super cow should be available to everyone, even to the most misfortune users not capable of having a valid environment variable. That makes the code slightly more ugly, so instead of requiring a young follower to produce a third version a high priest of the cult applied the finishing touches as he is used to the pain by now – and another round with the slowpoke high priest would have been a serious threat to the Debian release schedule which the cow would not approve. Closes: #848721 Signed-off-by: Super Cow Thanks: Chris Lamb for initial patch and guru meditation 2017-01-19T02:06:00Z David Kalnischkies david@kalnischkies.de 2017-01-19T01:53:35Z urn:sha1:3313eaf97c83177433478505c05815ab02f9782b The mode wasn't working at all if not used together with --fix-missing which while likely to come in pairs its legal to use standalone. Regression-in: eb1f04dda07c2b69549ad9fd793cca0e91841b3e 2017-01-19T00:09:05Z David Kalnischkies david@kalnischkies.de 2017-01-19T00:09:05Z urn:sha1:0d9081598afa051409b03dbdbe5025cd7ce59ba4 The update command acquires a lock on lists/, but at the end it will also require the dpkg/lock while building the binary caches. That seems rather pointless as we are only reading those files, not causing writing in them. This can also cause problems if a package installation is running and a background process (like cron) starts an update: If you are "lucky" enough the update process will pick the dpkg lock in between apt calls causing the installation process to fail. 2017-01-19T00:07:03Z David Kalnischkies david@kalnischkies.de 2017-01-19T00:07:03Z urn:sha1:22acd327ac39ffe3bb14b3e1f2d1f21761de13ca We get the archives/lock for clean – that is enough to ensure that other apt instances aren't interfering (or are being interfered with). We don't need to block actions involving dpkg. 2017-01-18T23:57:38Z David Kalnischkies david@kalnischkies.de 2017-01-18T10:31:13Z urn:sha1:33f982b90a4f77be18cb82daf8c79e9c5513761c Unlikely that anyone is actually running into this, but if we asked to not generate a cache and avoid it in the first step we shouldn't create one implicitly anyway by displaying the statistics. 2017-01-17T13:33:02Z Julian Andres Klode jak@debian.org 2017-01-17T13:33:02Z urn:sha1:b59a8c6e29015c4d19c4b39a63b328af7d87d1ee This will avoid people from thinking that they have to do nothing when they change the set of files. Gbp-Dch: ignore 2016-12-31T17:24:12Z David Kalnischkies david@kalnischkies.de 2016-12-31T17:24:12Z urn:sha1:ae73a2944a89e0d2406a2aab4a4c082e1e9da3f9 The idea is simple: Each¹ Find*( call starts with a call check if the given option (with the requested type) exists in the whitelist. The whitelist is specified via our configure-index file so that we have a better chance at keeping it current. the whitelist is loaded via a special (undocumented for now) configuration stanza and if none is loaded the empty whitelist will make it so that no warnings are shown. Much needs to be done still, but that is as good a time as any to take a snapshot of the current state and release it into the wild given that it found some bugs already and has no practical effect on users. ¹ not all in this iteration, but many 2016-12-31T01:29:21Z David Kalnischkies david@kalnischkies.de 2016-12-30T23:09:11Z urn:sha1:c15ba854b6736696f164e4d2c243a944e2d4006e Again no practical difference, but for consistency a boolean option should really be accessed via a boolean method rather than an int especially if you happen to try setting the option to "true" … Gbp-Dch: Ignore