Re: rust 1.72.0 in poudriere-devel keeps getting rebuilt

On Oct 20, 2023, at 11:06, void <void@f-m.fm> wrote:

> Hello arm@
> 
> What can I do to stop rust being rebuilt all the time in my poudriere-devel on rpi4?
> 
> 1. the version on pkg.freebsd.org at present is 1.72.0
> 
> 2. the Makefile in the ports tree also says 1.72.0
> 
> 3. poudriere is not building it in its filelist of ports-to-build, but as a dependency
> 
> 4. rust cannot build on a bigger faster machine with poudriere & qemu for arm64.aarch64 
> because rust will not build under qemu-user-static
> 
> 5. I've tried running a build with no make.conf for the poudriere to use. It still
> tries to build locally, instead of just downloading the binary like it downloads other unchanged binaries. No options for rust have been locally set, for the poudriere instance.
> 
> Is there a workaround that allows one to add the precompiled package so poudriere will use it to compile packages that need it?

poudriere(-devel) is explicit why it rebuilds rust in my context.
For example (from a recent test):

. . .
[00:00:04] Deleting curl-8.3.0_1.pkg: new version: 8.4.0
. . .
[00:00:05] Deleting rust-1.72.0.pkg: missing dependency: curl-8.3.0_1
. . .

So the curl that rust-1.72.0.pkg had previously been built with no longer
has a matching curl *.pkg . So rust is rebuilt based on the new version
of curl [via curl's new *.pkg version].

poudriere has no clue if or when or where its builds will be used for
later installation activity. It can not use that kind of context to
guide its actions as things are.

Having deleted rust-1.72.0.pkg poudriere rebuilds rust based on the new
curl dependency (version), even if rust would end up not being reinstalled
automatically due to a lack of a version number change. rust and/or curl
would be ready to be installed as needed.

(curl is just the dependency that happened to occur in my test. Any
special properties of curl as a dependency are not the point here:
it is just one example.)

The ports structure and poudriere do not do detailed analysis of if the
update to curl in this example would actually lead to a behaviorial
change or incompatibility for the detailed way curl is used by rust.
Similar points could be made for other dependencies that sometimes might
lead to rebuilding rust (but not necessarily automatically installing the
rebuilt rust: lack of a rust version number change, for example).

I'll note that there is a time between when the port curl goes from
8.3.0_1 to 8.4.0 and when a rust-1.72.0 package is available from
the FreeBSD servers that is based on rust built with curl 8.4.0's
package involved. During that period the only way to be consistent
with the updated ports tree is to build rust (and curl) locally.
Otherwise one would have to check out the port tree as it was at
an earlier time to match the packages currently available via pkg.
(But that tends to omit recent security fixes and such in parts of
the ports tree.)

(Again: curl is just an example of a dependency, one that happened to
show up in my test. Any special properties of curl as a dependency are
not the point here.)

"... add the precompiled package so poudriere will use it to compile
packages": So you want a rust to be used that does not track the
actual ports tree being built: allow the rust used to be out of sync
with the ports source tree for rust's dependencies, despite that the
rust version number does not indicate that full ports-source context.
I'll note that this specific wording is not explicitly asking that
an updated rust not be built at all. The difference between what is
installed/used vs. what is built is being mixed in an unclear manor
for the specific wording. Looks like you actually have a 2 component
request overall:

A) use of a prebuilt rust
and at the same time:
B) lack of doing any build of rust in the bulk run (even if the build
    is not used: otherwise the time would not be avoided)

If rust has a version update (judged strictly by version numbering
changes?) that is not available as a prebuilt package yet, the
intent for handling the ports-source vs. prebuilt mismatch is not
clear to me. Some number of rust dependencies could update during
such an interval, but the eventual pre-built rust could well be for
an earlier combination until an even later rebuild becomes available
as pre-built. (But what may have changed over that 2nd interval?)

You might what to be more explicit about what is acceptable when
(or other type of context).

===
Mark Millard
marklmi at yahoo.com