On Thu, Feb 16, 2017 at 05:21:48PM +0100, Marco d'Itri wrote: > On Feb 16, Adam Bolte <abolte@systemsaviour.com> wrote: > > Apparently anyone who uses timedatectl needs dbus, so why include it > > in the systemd package where it may not work, instead of a separate > > package with the dbus dependency? The command seems sufficiently > Because we (and the upstream maintainers too) do not want to split > systemd in endless tiny packages. This is not up for debate. Here I was thinking it was just the timedatectl command that was the only command with such an issue. But you imply that there are actually an endless number of commands that are included in the systemd package which all fail if recommended packages (aside from dbus) aren't installed? I had no idea! :) Seriously though, we all appreciate your work packaging and testing it all, and even your reluctance to fiddle unnecessarily with such a core package - but this one core command is creating problems currently which I'm sure many would find is worth taking the time to fix. > I also don't think updating all of the bootstrap tools to get a > > properly working Debian installation is the correct solution, although > > that's just my opinion. > It really depends on the purpose of that installation. If I understand correctly, you're saying it's okay for timedatectl to be broken in some installations if it's not expected to be used? If that understanding is correct, I don't see how it could ever be anticipated by the installation tool what the installation will forever be used for. I also don't think it's the job of the installation tool to make such a determination, or see why such tools should be limited to some sort of predefined scope. Are there any other examples in Debian of a command being broken if a package isn't installed? When I think of programs making use of Recommends, I think of such packages providing popular and important plugins, heavily used fonts, extra protocol support, and otherwise partial missing program functionality. However I can't think of any other commands, especially from those installed by default, that don't work at all if a recommended package isn't present. Feel free to point out examples if I'm in error. Incidentally, I believe that's why so many programs and scripts only check if the command is installed before using it, as opposed to checking the command is setup to work correctly as well (where doing so for every command in, say, a simple shell script, would not always be very reasonable). It breaks some implied level of trust of the developers of such programs and scripts. I do believe the ideal solution is to package the command separately with a Depends on dbus, and have systemd Suggests or Recommends the new package. If the command doesn't exist, scripts should at least handle that case since many installations don't even have systemd. If it does exist, there's no missing dependencies preventing it from working (although it still won't work in a chroot or other environment where the dbus package is installed but daemon perhaps not running, but timedatectl likely wouldn't be installed in such an environment anyway). It would also mean that packages calling timedatectl exclusively and without a fallback would need to depend on the new package, hence it's possible some other packages would need a simple control file update. I can't imagine it would be a problem. If my arguments for haven't been compelling so far, I'm going to stop harping on about it. Even if I haven't been convincing, thanks for hearing me out. -Adam
Attachment:
signature.asc
Description: Digital signature