Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.5_alpha2 2017-06-28T17:18:47Z 2017-06-28T17:18:47Z David Kalnischkies david@kalnischkies.de 2017-05-28T15:44:11Z urn:sha1:24b5bc4e41ed527799a9fa01dec9c29294d0a3f2 If we have a user sitting around we can let 'apt' ask the user for a confirmation rather than print errors at the end and require the user to figure out which commandline flags are needed to confirm the changes non-interactively. 2017-06-28T17:18:47Z David Kalnischkies david@kalnischkies.de 2017-04-12T15:39:06Z urn:sha1:081fbea14d12f79c8d91ce4fe1f1004c7bc08656 The value of Origin, Label, Codename and co can be used in user configuration from apts own pinning to unattended upgrades. A repository changing this values can therefore have serious effects on the behaviour of apt and other tools using these values. In a first step we will generate error messages for these changes now explaining the need for explicit confirmation and provide config options and commandline flags to accept them. 2017-06-28T17:17:57Z David Kalnischkies david@kalnischkies.de 2017-06-28T10:57:51Z urn:sha1:cbaf353ead58aa9eefe51542b6ad91e69b6289ce The exception was made to give (script) users a one-release grace period to adapt their setup to deal with apt enforcing signing of repositories. As we are now at the start of a new release cycle its as good a time as any to lift it now. Removes-Exception: 952ee63b0af14a534c0aca00c11d1a99be6b22b2 2017-06-26T21:31:15Z David Kalnischkies david@kalnischkies.de 2017-04-28T16:18:28Z urn:sha1:6829c5420b4c2e434489e837cad6f3fd09fa3ab3 Adopting this change in other frontends will require source changes as well similar to our own changes in apt-private/. 2017-06-26T21:31:15Z David Kalnischkies david@kalnischkies.de 2017-05-29T16:02:28Z urn:sha1:3243dc51579f42971b8c5a7a123a77352aecc6f7 Showing messages related to downloading in a mode which can't download is pretty pointless, so instead of trying harder to make it so that these messages do not trigger just skip them entirely. That the message triggered here is an artifact of the implementation in which the download items are finished, while the code expects them to be still pending – even the in a previous run completely downloaded files. Closes: 863635 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.