Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.4_beta3 2016-12-31T17:24:12Z 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 2016-12-31T01:29:20Z David Kalnischkies david@kalnischkies.de 2016-12-29T11:55:12Z urn:sha1:cfc11b2e1d8480727208b9d3e9577172de9a4038 Users end up believing that this is a --force mode as -f is common for that, but apt doesn't have such a mode and --fix-broken is really not about forcing something but actually trying to fix the breakage which tends to be the result of a user forcing something on its system via low-level forced dpkg calls. Example: The "common" pattern of "dpkg -i ./foo.deb; apt install -f" is nowadays far better dealt with via "apt install ./foo.deb". And while at it the two places handing out this suggestion are changed to use the same strings to avoid needless translation work in the future and the suggestion uses 'apt' instead of 'apt-get' as this will be run interactively by a user, so its a good opportunity to showcase what we can do and will allow us to be more helpful to the user. Closes: #709092 Thanks: Kristian Glass for initial patch! 2016-12-31T01:29:20Z David Kalnischkies david@kalnischkies.de 2016-12-29T11:41:23Z urn:sha1:abbe74b2b4690b9138da94d26a7e45ad80a3bf6c The config list APT::Build-Essential gets a similar treatment to other lists now by having the value of the option itself be an override for the list allowing to disable build-essentials entirely as well as adding/overriding as usual by now in other lists. Reported-By: Johannes 'josch' Schauer on IRC 2016-12-31T01:29:20Z David Kalnischkies david@kalnischkies.de 2016-12-29T11:12:01Z urn:sha1:0c646119dea438abb3ee8797994d016ba6834cd2 The implementation is quite different compared to --arch-only due to ABI reasons but functionality wise they are similar and usually both available for symmetry at least. Closes: #845775 2016-12-16T12:50:00Z David Kalnischkies david@kalnischkies.de 2016-11-25T16:42:47Z urn:sha1:d20643cc0ac89ee30cf0e546d689e67085294ace In bug #757534 the opposite direction was initially requested, but what we did end up with was having a possibility to configure the options passed to dpkg. The reasoning given their and in #724744 is specific why apt doesn't need the checks to be performed by dpkg. In fact, what these two reports show is that if those checks are run people end up being confused about the requirement of them being run, so given the best case those checks can do is do nothing (visibly) while the worst cases are warnings and errors which are neither we are from a security point better of with disabling them – as (as mentioned in the bugreports) false positives for issues are really really bad in a security context. Closes: 724744 2016-12-16T12:50:00Z David Kalnischkies david@kalnischkies.de 2016-11-25T15:23:02Z urn:sha1:fc336f09356c1db63094e377a65033d5ec00b983 We are calling system() in this code paths, so all we do here is having a single child performing the action while the parent waits for it to finish… with the added strangeness of not having our usual error message collection and giving up after first failure even if told to act on multiple packages. 2016-12-16T12:50:00Z David Kalnischkies david@kalnischkies.de 2016-11-25T14:51:21Z urn:sha1:58ebb3017baf46e33a9bb2c1779d6daede27d108 That was the case already for tar-only and diff-only, but in a more confusing way and without a message while dsc "worked" before resulting in a dpkg-source error shortly after as tar/diff files aren't available… 2016-11-09T15:18:54Z Johannes Schauer josch@debian.org 2016-11-09T14:28:15Z urn:sha1:c5f22e483cc0f31f2938874370ac776e40792069 These new enum values might cause "interesting" behaviour in tools not expecting them – like an old apt would think a Build-Conflicts-Arch is some sort of Build-Depends – but that can't reasonably be avoided and effects only packages using B-D/C-A so if there is any breakage the tools can easily be adapted. The APT_PKG_RELEASE number is increased so that libapt users can detect the availability of these new enum fields via: #if APT_PKG_ABI > 500 || (APT_PKG_ABI == 500 && APT_PKG_RELEASE >= 1) Closes: #837395 2016-11-02T08:36:49Z David Kalnischkies david@kalnischkies.de 2016-09-10T17:52:11Z urn:sha1:952171787a0b865c17d5c9476e272106383ae93a In effect this is an extension of the 6 years old commit a8dfff90aa740889eb99d00fde5d70908d9fd88a which uses the autoremover to remove packages again from the solution which are no longer needed to be there. Commonly these are dependencies of packages we end up not installed due to problem resolver decisions. Slightly less common is the situation we deal with here: a package which we wanted to upgrade sporting a new dependency, but ended up holding back. The problem is that all versions of an installed reverse dependencies can bring back a "garbage" package – we need to do this as there is nothing inherently wrong in having garbage packages installed or upgrade them, which itself would have garbage dependencies, so just blindly killing all new garbage packages would prevent the upgrade (and actually generate errors). What we should be doing is looking only at the version we will have on the system, disregarding all old/new reverse dependencies. Reported-By: Stuart Prescott (themill) on IRC