A strange error while installing a package [Kuber.jl] on Windows

[findmyway]

Following are the error messages while installing Kuber.jl on Windows:

ERROR: Error when installing package Kuber:
AssertionError: length(dirs) == 1
Stacktrace:
 [1] install_archive(::Array{String,1}, ::Base.SHA1, ::String) at C:\cygwin\home\Administrator\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.1\Pkg\src\Operations.jl:482
 [2] macro expansion at C:\cygwin\home\Administrator\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.1\Pkg\src\Operations.jl:596 [inlined]
 [3] (::getfield(Pkg.Operations, Symbol("##26#29")){Symbol,Pkg.Types.Context,Dict{Base.UUID,Base.SHA1},Dict{Base.UUID,Array{String,1}}})() at .\task.jl:259

julia> versioninfo()
Julia Version 1.1.0
Commit 80516ca202 (2019-01-21 21:24 UTC)
Platform Info:
  OS: Windows (x86_64-w64-mingw32)
  CPU: Intel(R) Xeon(R) CPU E5-1630 v3 @ 3.70GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-6.0.1 (ORCJIT, haswell)

Ref: JuliaComputing/Kuber.jl#12

[KristofferC]

When we extract the tarball for the package we assume that there is only one directory in it, the directory of the release. This seems to fail here. Is it only for this package?

It could be something similar as the workaround at:

Pkg.jl/src/Operations.jl

Lines 492 to 494 in 896505f

	# 7z on Win might create this spurious file
	filter!(x -> x != "pax_global_header", dirs)
	@assert length(dirs) == 1

[findmyway]

Yeah, for now I only find the error with Kuber.jl

[KristofferC]

It does have a bunch of more files:

Perhaps we can just take the directory that starts with the name of the package?

[StefanKarpinski]

Do we know why it has all that other stuff in there?

[KristofferC]

I found https://stackoverflow.com/questions/34688392/paxheaders-in-tarball but I don't know why this package specifically has these files.

[StefanKarpinski]

@tanmaykm, any idea?

[KristofferC]

#1943 (comment)

[KristofferC]

Tar.jl knows how to extract tarballs with POSIX extended features, so it will correctly extract these.

[StefanKarpinski]

Summary (for myself as much as anyone else): we used to use 7z to extract tarballs, but it doesn't understand POSIX extended headers so if anyone created a package or artifact with very long file names or deeply nested paths, the old Pkg client would be unable to correctly extract the tarball with 7z. We now use Tar.extract which does know how to extract these, so this is no longer a problem.