On Sun, Dec 06, 2015 at 03:32:02PM +0100, Jakub Wilk wrote: > * David Kalnischkies <david@kalnischkies.de>, 2015-12-06, 14:55: > >I changed various places to use "command -v" anyhow as we indeed use it > >for no good reason, so why not… > > Well, Policy says that /bin/sh scripts must follow SUSv3 (+ some > extensions), and "command -v" is only optional in SUSv3. Right… it can never be easy (in shell), can it? btw: SUSv4 explains UP with "[…] optional within the POSIX base standard but mandatory in the Single UNIX Specification". At least 'command -v' is easier to grep for and that says 5 files: 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.] Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature