apt/cmdline, branch 1.1.4

part revert, part redo 'which' replacement

2015-12-06T23:09:10Z

In e75e5879 'replace "which" with "command -v" for portability' I missed that command -v isn't actually required to be available in debian, so for the 5 files we are using it: Two (abicheck/run_abi_test & test/integration/framework) are called in environments were I believe sh is at least dash or 'better' as the first one is "interactive" for apt developers and the later is sourced by ~200 tests in the same directory run by hand and ci-services – for the later we have pulled some uglier hacks for worser things already, so if there should actually end up needing something more compatible we will notice eventually (and the later actually had a command -v call for some time already and nobody came running). debian/rules and debian/apt.cron.daily I switched back to which as that is more or less debian-specific or at least highly non-critical. That leaves cmdline/apt-key.in with a bunch of calls where I will implement that functionality in shell as this is relatively short-lived as it is used to detect wget (for net-update, which Michael wants to revive and in that process will properly use apt-helper instead of wget) and to detect gpg vs. gpg2 systems, where the earlier is supposed to go away in the longrun (or the later, but by replacing the earlier…). [and this gpg/gpg2 detection is new in sid, so I have some sympathy for that being a problem now.] Thanks: Jakub Wilk for pointing out #747320

replace run-parts with find|sort to avoid debianutils usage

2015-12-06T13:46:11Z

After e75e5879 the reason for an implicit dependency on debianutils (which is essential for debian, but likely not on other systems) was just two uses of run-parts, which can be replaced with the a lot more portable find-piped-into-sort duo.

replace "which" with "command -v" for portability

2015-12-06T13:03:35Z

which is a debian specific tool packaged in debianutils (essential) while command is a shell builtin defined by POSIX. Closes: 807144 Thanks: Mingye Wang for the suggestion.

apt-helper.cc: include for atoi

2015-12-06T12:30:51Z

Include to ensure that atoi(3) is defined to improve general portability and fix a specific build failure on Android. Closes: 807031

drop some needlessly public declarations in libapt-private

2015-11-29T16:00:11Z

Git-Dch: Ignore

move 'unmet' handling into libapt-private

2015-11-29T14:49:55Z

Git-Dch: Ignore

use function pointers instead of weak symbols for cmdline parsing

2015-11-29T12:12:38Z

Passing function pointers around while working on this was very icky, but if weak symbols are too much to ask for… Reverts "do not use "-Wl,-Bsymbolic-functions" during the build to avoid breakage" aka a5fc9be36211a290a7abc3ca2a8bf98943bc1f57.

review of new/changed translatable program strings

2015-11-21T17:04:29Z

Reference mail: https://lists.debian.org/debian-l10n-english/2015/11/msg00006.html

wrap every unlink call to check for != /dev/null

2015-11-04T17:42:28Z

Unlinking /dev/null is bad, we shouldn't do that. Also, we should print at least a warning if we tried to unlink a file but didn't manage to pull it of (ignoring the case were the file is /dev/null or doesn't exist in the first place). This got triggered by a relatively unlikely to cause problem in pkgAcquire::Worker::PrepareFiles which would while temporary uncompressed files (which are set to keep compressed) figure out that to files are the same and prepare for sharing by deleting them. Bad move. That also shows why not printing a warning is a bad idea as this hide the error for in non-root test runs. Git-Dch: Ignore

revamp all tools help messages

2015-11-04T17:04:05Z

The general idea is: A small paragraph on the tool itself as a description, a list of the most used (!= all) commands available in the tool, a remark where to find more information on the tool and its commands (aka: in the manpage) and finally a common block referring to even more manpages. In exchange options are completely omitted from the output as well as deprecated or obscure commands. (Better) Information about them is available in the manpages anyway and the few options which were listed before were also the least interesting ones (-o -c -q and co are hardly of interest for someone totally new looking to find info by asking for help and anyone with a bit of experience doesn't need this short list. Those would need a list of options applying to the command they call, but they are too numerous and command specific to list them sanely in this context.