Closed silene closed 9 years ago
Actually, from looking at opam code, it does look like a real bug. As far as I understand the issue, as soon as opam notices a colon in a file name, even if there are slashes before it, it assumes that it is a remote file that should be fetched by rsync. More precisely, in the OpamLocal.rsync_file function, rather than executing
Done (Not_available src_s)
as it should, it executes
call_rsync ( rsync_arg :: args @ [ src_s; dst_s ])
which leads to the aforementioned failure. Just to be sure, I removed the colons from the coq/repo-stable repository. Then downloading and building succeeded.
Ok, thanks for the report! Is this on 1.2 or master ? Because I've just been sanitising download handling.
I can confirm the bug
Ok, here is the issue:
it's expected that OPAM will attempt to get the +opam.tar.gz
archive, for http and rsync repos -- this allows for local caching of archive using opam-admin
, and local testing of repositories. The issue is that rsync returns the same error on failing to copy a single file's attributes, on which we just want to print a warning, and completely failing, so OPAM doesn't treat it a fatal error.
I'll be adding a test after the call to rsync to check if it was successful.
I have a local repository (a local checkout of the coq/repo-stable repository):
I already have used this setup successfully some times ago (but perhaps not with opam 1.2), but now when I try to install a package described in this repository, I get the following behavior:
When using the --debug flag, I see that opam tried to use rsync:
instead of downloading the tarballs described in the repository.
This is probably not a bug, probably just a misconfiguration, but the documentation was not helpful in understanding why rsync is used rather than curl for this local repository.