Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ararslan
Copy link
Member

@ararslan ararslan commented Jul 6, 2017

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 JuliaMath/FFTW.jl#20.

Thanks to @nalimilan for figuring this all out!

@ararslan ararslan requested review from nalimilan and tkelman July 6, 2017 18:35
@@ -425,8 +425,8 @@ function generate_steps(dep::LibraryDependency,h::AptGet,opts)
end
sudo = get(opts, :sudo, has_sudo[]) ? `sudo` : ``
@build_steps begin
println("Installing dependency $(h.package) via `$(sudoname(sudo))apt-get install $(h.package)`:")
`$sudo apt-get install $(h.package)`
info("Installing dependency $(h.package) via `$(sudoname(sudo))apt-get install $(h.package)`:")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You forgot to add the -y here and for pacman.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh right, I guess it should say that in the informational message too

@@ -461,8 +461,8 @@ function generate_steps(dep::LibraryDependency,h::Zypper,opts)
end
sudo = get(opts, :sudo, has_sudo[]) ? `sudo` : ``
@build_steps begin
println("Installing dependency $(h.package) via `$(sudoname(sudo))zypper install $(h.package)`:")
`$sudo zypper install $(h.package)`
info("Installing dependency $(h.package) via `$(sudoname(sudo))zypper install -n $(h.package)`:")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't that be -y too? At least that's why https://en.opensuse.org/SDB:Zypper_manual_%28plain%29 says.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I read that it was -n for --no-confirmation or something like that. I can make it -y.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-n seems to be an obscure option about names.

@tkelman
Copy link
Contributor

tkelman commented Jul 6, 2017

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

@nalimilan
Copy link
Member

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
Copy link
Contributor

tkelman commented Jul 6, 2017

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
Copy link
Member Author

ararslan commented Jul 6, 2017

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
Copy link
Member

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
Copy link
Contributor

musm commented Jul 28, 2017

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

@robbystk
Copy link

robbystk commented May 25, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants