openSUSE still calling for Yast permissions in using PyPlot

[colbec]

In #188 there was an effort to eliminate a call to Yast (ref: JuliaPy/PyPlot.jl#183) when issuing request using PyPlot by adding the zypper package manager. This seems to be now implemented in the release 0.3.21 installed on my machine this morning. Unfortunately this did not resolve the issue of the call to Yast, which still pops up asking for root permissions. Nothing is installed or removed; cancelling it allows the process to continue. It is an annoyance but cosmetic; just a note to file.

[tkelman]

Whichever dependency is invoking BinDeps can now add a zypper specific provider information, which may help here. Can you narrow the issue down to one of PyPlot's dependencies?

[colbec]

Examining the Require list for PyPlot shows: julia 0.3, PyCall 1.1, Colors, LaTeXStrings, Compat 0.4, Conda. I tried a Pkg.build("...") on each of these and nothing called for Yast. Maybe it is a dependency of a dependency. I will check when I can.

[tkelman]

Sounds good. I actually have leap on a partition now so I can also play with this, but I don't boot into it as often as I like since I haven't figured out how to get hdmi output to work properly.

[colbec]

It seems to be a good idea to wait a day or so for files to go stale, then odds are picked up more easily. This morning I did a git pull && make on Julia master, then retried Pkg.build() on the dependencies mentioned above in backwards order. Conda, Compat, LaTeXStrings, Colors all ok, but PyCall wanted to talk unnecessarily to Yast.

Examining the current Require of PyCall we have [julia 0.4, Compat 0.7.1, Dates, Conda 0.1.6].

1. Dates is new, but there is a note in the Dates page to say that Dates is now in Base so in theory we can ignore that since it would have been picked up already?
2. There are inconsistencies between the two require lists. No idea what ramifications this will lead to.

[nalimilan]

Dates is indeed in Base now, and anyway I wouldn't expect it to install dependencies as it's pure Julia and doesn't use BinDeps at all. But PyCall itself is the likely culprit, as it may call Python code which calls Yast.

[tkelman]

I think Elliot figured out why this was happening over at JuliaCrypto/Nettle.jl#68 - apparently opensuse has apt-get and when it gets called that triggers YaST. So I bet if we rearranged things a little here to try zypper first, and skip testing for apt-get if zypper succeeds, you wouldn't get the popup any more. Or maybe just swap the order of success(apt-get -v) && success(apt-cache -v), ref https://github.com/JuliaLang/BinDeps.jl/pull/211/files

[colbec]

Some further information. Please note comments below apply to Leap 42.1 only, I understand that on openSUSE 13.1 a version of apt-get may still be provided but by a different package.

Please see output below. Note that "success(apt-get -v)" can result in three answers depending on the state of the system. The first comes when the openSUSE package "zypper-aptitude" (provides compatibility to Debian's aptitude command using zypper) is not installed. The second comes when "zypper-aptitude" is installed; the system responds to the success call by opening Yast and waiting for a response. If the user says cancel then the response to success is false, and if the user responds with OK go ahead then the response is true.

The programme apt-cache is not available at all in any standard package on openSUSE that I can find, so the suggestion by @tkelman above to check apt-cache existence first might be good particularly if the logical check is a shortcut LH side only type.

I have removed the zypper-aptitude compatibility completely so now hopefully I will not see Yast again, but will post back with results.

ref: JuliaCrypto/Nettle.jl#68

julia> success(`apt-get -v`)
ERROR: could not spawn `apt-get -v`: no such file or directory (ENOENT)
 in _jl_spawn(::String, ::Array{String,1}, ::Ptr{Void}, ::Base.Process, ::Base.DevNullStream, ::Base.DevNullStream, ::Base.DevNullStream) at ./process.jl:319
 in #416 at ./process.jl:468 [inlined]
 in setup_stdio(::Base.##416#417{Cmd,Ptr{Void},Base.Process}, ::Tuple{Base.DevNullStream,Base.DevNullStream,Base.DevNullStream}) at ./process.jl:458
 in #spawn#415(::Nullable{Base.ProcessChain}, ::Function, ::Cmd, ::Tuple{Base.DevNullStream,Base.DevNullStream,Base.DevNullStream}) at ./process.jl:467
 in (::Base.#kw##spawn)(::Array{Any,1}, ::Base.#spawn, ::Cmd, ::Tuple{Base.DevNullStream,Base.DevNullStream,Base.DevNullStream}) at ./<missing>:0
 in success(::Cmd) at ./process.jl:597

julia> success(`apt-get -v`)
false

julia> success(`apt-get -v`)
true

[colbec]

@tkelman We have managed to engage the interest of the openSUSE developers on this issue. There is an offer in openSUSE/zypper#98 to have calls to apt-get on openSUSE with zypper-aptitude installed to return the zypper version string with no call to Yast. This would enable BinDeps to receive a string from apt-get which does not contain the string "apt-get". I don't have an aptitude system to test, but would this enable a Julia test such as contains(apt-get_version_test,"apt-get") to successfully test for aptitude as a principal actor on the host system?

[tkelman]

Something like that might work, but wouldn't necessarily help existing opensuse versions, right? Since && does short-circuit, I think it would be safe to change that line to

const has_apt = try success(`apt-cache -v`) && success(`apt-get -v`) catch e false end