Opened 4 years ago
Last modified 7 months ago
#60756 new enhancement
Tell the user when fetching a binary failed and a build from source will occur
Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | base | Version: | 2.6.2 |
Keywords: | Cc: | kurthindenburg (Kurt Hindenburg) | |
Port: |
Description
We constantly get bug reports from users who misunderstand how MacPorts works with regard to binaries and building from source. For example, users often report that a port cannot be installed "because the file is not on the servers". The file they are referring to is the binary archive, and this confusion is understandable since MacPorts prints messages about trying to download the binary archive and the log contains 404 not found errors. The user doesn't understand that this is not the real problem; that MacPorts is then building from source, perhaps using a source tarball that was already on their system; that the build from source is failing; and that that is the real problem that needs to be addressed. See #60731 for a recent instance of this.
While I am conscious of the need to streamline MacPorts output and not overwhelm the user with irrelevancies, I think it would improve user understanding and reduce the amount of reeducation that we have to do in each ticket if MacPorts would print a message if it failed to find a binary archive on the server and will then build from source. We might also be more explicit and refer to archives specifically as binary archives, to differentiate them from source code archives.
Here's what we currently print:
---> Fetching archive for p5.30-mozilla-ca ---> Attempting to fetch p5.30-mozilla-ca-20200520_0.darwin_19.noarch.tbz2 from https://packages.macports.org/p5.30-mozilla-ca ---> Attempting to fetch p5.30-mozilla-ca-20200520_0.darwin_19.noarch.tbz2 from http://lil.fr.packages.macports.org/p5.30-mozilla-ca ---> Attempting to fetch p5.30-mozilla-ca-20200520_0.darwin_19.noarch.tbz2 from http://nue.de.packages.macports.org/p5.30-mozilla-ca ---> Verifying checksums for p5.30-mozilla-ca Error: Checksum (rmd160) mismatch for Mozilla-CA-20200520.tar.gz
Here's an example of how we could improve the output:
---> Fetching binary archive for p5.30-mozilla-ca ---> Attempting to fetch p5.30-mozilla-ca-20200520_0.darwin_19.noarch.tbz2 from https://packages.macports.org/p5.30-mozilla-ca ---> Attempting to fetch p5.30-mozilla-ca-20200520_0.darwin_19.noarch.tbz2 from http://lil.fr.packages.macports.org/p5.30-mozilla-ca ---> Attempting to fetch p5.30-mozilla-ca-20200520_0.darwin_19.noarch.tbz2 from http://nue.de.packages.macports.org/p5.30-mozilla-ca Building from source because a binary archive could not be found ---> Verifying checksums for p5.30-mozilla-ca Error: Checksum (rmd160) mismatch for Mozilla-CA-20200520.tar.gz
If we let MacPorts know which ports are distributable we could change that message to be more specific:
Building from source because the binary archive is not distributable ---> Verifying checksums for p5.30-mozilla-ca Error: Checksum (rmd160) mismatch for Mozilla-CA-20200520.tar.gz
We might also want to reword the output for fetching the source code. We currently print:
---> Fetching distfiles for p5.30-mozilla-ca ---> Attempting to fetch Mozilla-CA-20200520.tar.gz from https://distfiles.macports.org/perl5
What if we change it to:
---> Fetching source code for p5.30-mozilla-ca ---> Attempting to fetch Mozilla-CA-20200520.tar.gz from https://distfiles.macports.org/perl5
This would clear up confusion for users who don't know what we mean by "distfile" and would also make the message more accurate since it would accommodate those ports that don't fetch distfiles but fetch from a VCS like git instead. The new wording would be inaccurate for ports that download and repackage an existing binary but that's very few ports so it can probably be ignored.
Change History (4)
comment:1 Changed 4 years ago by mf2k (Frank Schima)
comment:2 Changed 4 years ago by kurthindenburg (Kurt Hindenburg)
Cc: | kurthindenburg added |
---|
It is a trivial item to change the messages. I've been meaning to try to get some form of "distributable" in base.
comment:3 Changed 4 years ago by kurthindenburg (Kurt Hindenburg)
https://github.com/macports/macports-base/pull/230
I haven't figured out how to change the messages when the archive fetch failed.
"Building from source because a binary archive could not be found"
comment:4 Changed 7 months ago by ryandesign (Ryan Carsten Schmidt)
Has duplicate #68869.
Changing "archive" to "binary archive" as I first suggested may not be the best. Not all archives contain binaries; some are just data files. We seem to have settled on the word "archive" to describe our pre-built downloads, but it's not the clearest term. After all, most distfiles are technically archives too.
Similarly, changing "distfiles" to "source code" may not be the best, since not all distfiles are source code. Some are pre-compiled binaries, as Frank pointed out, and some are data files. Some ports may even use a combination of file types.
Project-wide, we should come up with better terms to differentiate these. Maybe something like "Fetching pre-built archive of $port" vs "Fetching files to build $port".
Replying to mf2k:
Maybe we should also add a new keyword to base to note that the Portfile is downloading a binary and not source code:
distfiles_type source [default] distfiles_type binaryIt could even not try to run the configure and build phases when it is binary.
For the purpose of changing the output to indicate what kind of file is being fetched, it would be simpler to come up with a single message that applies in all cases.
For the purpose of not running the configure and build phases when fetching a binary, it's off topic for this ticket.
Maybe we should also add a new keyword to base to note that the Portfile is downloading a binary and not source code:
It could even not try to run the configure and build phases when it is binary.