Add 'no confirmation' flag to providers, write provider info to STDERR

[ararslan]

STDOUT in the println calls in generate_steps is getting swallowed, so instead we should use info, which prints to STDERR. This gets through and prints as expected.

Each package manager has a "no confirmation" flag, but for whatever reason we weren't using it for anything but FreeBSD. Apparently Yum actually fails when it expects interactive input but doesn't get it, which seems to be what's causing https://github.com/JuliaMath/FFTW.jl/issues/20.

Thanks to @nalimilan for figuring this all out!

[tkelman]

Adding this flag is a really dangerous thing to do when sudo is involved.

[nalimilan]

Adding this flag is a really dangerous thing to do when sudo is involved.

We're only installing packages, so nothing terrible should happen. I guess we could check what happens in case of conflicts, i.e. do some package managers remove conflicting packages to be able to install the new one? I would expect something like --force to be required for that.

The alternative is to find out why yum fails to run ask for confirmation from the user, but I guess that's related to the fact that the process is detached and we haven't found a solution to that for a long time.

[tkelman]

Conflict resolution would be an especially harmful case. I've seen apt-get conflicts try to remove build-essential and everything depending on it before. That would be really nasty to do without giving a chance to confirm.

[ararslan]

If this isn't a good way to go and we can't figure out why Yum fails without input, should I just omit the Yum provider for FFTW so that CentOS et al. always have to build it from source?

[nalimilan]

Conflict resolution would be an especially harmful case. I've seen apt-get conflicts try to remove build-essential and everything depending on it before. That would be really nasty to do without giving a chance to confirm.

@tkelman I think we need to check this. The manpage for apt-get says:

-y    Automatic yes to prompts. Assume "yes" as answer to all prompts and
      run non-interactively. If an undesirable situation, such as changing a held
      package or removing an essential package, occurs then apt-get will abort. 

There's also --force-yes/-f, which apparently will happily do anything you ask and is therefore not recommended. But indeed there seems to be some evidence that apt-get install proposes to remove packages when installing others.

On the contrary, regarding yum, I've just tried locally installing the julia-doc-0.5.1 package which requires julia, which would conflict with the julia-0.6.0 package already installed, and I need to pass --allowerasing for the command to have any effect:

$ sudo yum -y install julia-doc-0.5.1
Error: package julia-doc-0.5.1-1.fc25.noarch requires julia = 0.5.1-1.fc25, but none of the providers can be installed
(try to add '--allowerasing' to command line to replace conflicting packages)

I've checked that CentOS 7 has the same behavior.

So a solution would be to make the change only for yum, which is where the problem (is known to) happen anyway. Of course we could also fix the underlying problem which blocks user interaction, if somebody has ideas about that.

If this isn't a good way to go and we can't figure out why Yum fails without input, should I just omit the Yum provider for FFTW so that CentOS et al. always have to build it from source?

@ararslan Unfortunately this will likely fail on many systems too, since you need to have the compiler toolchain installed, which probably isn't the case of most users.

[musm]

@ararslan perhaps this can be updated to just change println -> info since that is non controversial

[robbystk]

Pacman will not auto-confirm removals when given --noconfirm if there are conflicts, so it is safe to call pacman --noconfirm. Pacman will also do nothing if given no input without --noconfirm, just like Yum as mentioned above. Adding --noconfirm when using pacman will cause it to work properly and install the packages.