Opened 5 years ago
Last modified 3 years ago
#59463 new defect
Binary-only mode requested with no usable archive sites configured
Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | base | Version: | 2.6.2 |
Keywords: | Cc: | fhgwright (Fred Wright) | |
Port: |
Description
I reported this before in #54743 with regard to a Portfile in the main ports tree and it was fixed. But the problem still exists if the Portfile is not in the ports tree:
$ cd /tmp/icu $ ls Portfile files $ sudo port -b install Error: Failed to archivefetch icu: Binary-only mode requested with no usable archive sites configured Error: See /opt/local/var/macports/logs/_private_tmp_icu/icu/main.log for details. Error: Follow https://guide.macports.org/#project.tickets to report a bug. Error: Processing of port icu failed $
In this case, if I try without the -b
flag, MacPorts unexpectedly tries to build from source:
$ sudo port install ---> Fetching distfiles for icu ---> Verifying checksums for icu ---> Extracting icu ---> Applying patches to icu ---> Configuring icu ^CError: Aborted: SIGINT received.
I don't want a build from source. I want the binary.
Overwriting the Portfile in the main ports tree allows me to install the binary:
$ sudo cp Portfile $(port file icu) $ sudo cp files/* $(port dir icu)/files/ $ sudo port -b install icu ---> Fetching archive for icu ---> Attempting to fetch icu-58.2_2.darwin_18.x86_64.tbz2 from http://packages.macports.org/icu ---> Attempting to fetch icu-58.2_2.darwin_18.x86_64.tbz2.rmd160 from http://packages.macports.org/icu ---> Installing icu @58.2_2 ---> Deactivating icu @65.1_0 ---> Cleaning icu ---> Activating icu @58.2_2 ---> Cleaning icu
But it's dumb that I have to do that.
Change History (6)
comment:1 Changed 5 years ago by jmroot (Joshua Root)
comment:2 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)
I hadn't made changes. I just wanted to install an older version of a port.
comment:3 follow-up: 5 Changed 3 years ago by raimue (Rainer Müller)
The problem is that we don't know whether the binary archive was built from this Portfile. See the commit message in 9c147ed1379254954063ce7354c35369dfe4b945/macports-base.
But as a workaround, you could define archive sites in the ports tree at _resources/port1.0/fetch/archive_sites.tcl
to indicate that you want to use the binary archives of the official MacPorts ports tree.
comment:4 Changed 3 years ago by fhgwright (Fred Wright)
Cc: | fhgwright added |
---|
comment:5 Changed 3 years ago by fhgwright (Fred Wright)
Replying to raimue:
The problem is that we don't know whether the binary archive was built from this Portfile. See the commit message in 9c147ed1379254954063ce7354c35369dfe4b945/macports-base.
But as a workaround, you could define archive sites in the ports tree at
_resources/port1.0/fetch/archive_sites.tcl
to indicate that you want to use the binary archives of the official MacPorts ports tree.
That doesn't work. It seems that sources.conf only affects where to look for the ports
tree, not the _resources
tree, so there's no way to get it to see a locally-modified (or even locally-unmodified) file under _resources
. I've run into the same problem when trying to test a PortGroup change in the local sparse overlay tree.
comment:6 Changed 3 years ago by kencu (Ken)
base looks in the _resources
directory of the port tree where the Portfile is located first.
For most things it will then fall back to the main (default) port tree, and use that _resources
directory.
But for archive_sites, it will not fall back.
Although I haven't tested the archive_sites overrides, the rest of the mechanism does indeed work properly for me when I have used it.
I do think this messes up a lot of people who are trying out changes in PortGroups however, in particular (and the compiler selection tweaks, etc, in those files).
What if you had made changes to the port? Fetching an archive built from a different Portfile would be incorrect.