Re: rust 1.72.0 in poudriere-devel keeps getting rebuilt

On Oct 21, 2023, at 19:04, void <void@f-m.fm> wrote:
> 
> Hello,

Hello.

> On Sat, 21 Oct 2023, at 23:45, Mark Millard wrote:
> 
>> "... 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)
> 
> I need to say at the start that although I've done *some* testing of the
> situation, I've not done *comprehensive* testing.
> 
> I'd like poudriere to download pre-built rust and whatever else rust 
> needs if poudriere is told to compile ports that require rust, ultimately 
> incorporating the rust package into the poudriere pkg collection.

poudriere's purpose is to build packages based strictly on
the dependencies in the ports tree it is working with (plus
the options specifications), no deviations. This involves
each builder being a clean environment that does not use
ports or packages that might be inconsistent with that.

(The means of controlling what the rust package is based on
is controlling the ports tree content [and options].)

> poudriere is not setting any make options for the build outside what
> would be there by default.
> 
> I can understand rust needing compiling by poudriere locally, if options 
> for rust itself have been changed in the local ports tree which deviate 
> from the default. Or if rust itself has a version change. 
> That isn't the case here.

You have not reported examples of what poudriere reports about why it
deletes the pre-existing rust build at various examples, such as:

[00:00:10] Deleting rust-1.72.0.pkg: missing dependency: curl-8.3.0_1

or why you think such a delete that it reports should not be necessary
at the time. Similar wording applies relative to it not downloading
a rust that was based on curl 8.3.0_1 when the prots tree has curl
8.4.0 instead --but there is no messaging about why the download was
skipped as far as a know. In some ways that is too bad because
skipping a download is analogous to doing the delete of a prior
local build.

(As stands, rust built based on curl 8.4.0 that was in the ports tree
did not exist to download at the time for the above.)

For poudriere's purposes that it is designed for, asking for it to
ignore the dependencies is a big ask. (So there is no grand scale,
detailed control over ways of avoiding tracking dependencies.)

> It seems that every time poudriere runs, because the ports list has 
> some programs requiring rust, the rust pkg gets rebuilt.

Ports that use rust (to build or run) are why rust is needed at
all but not why rust ends up being rebuilt instead of used
as-is/as-available-for-download (given the "needed at all status).

Why rust ends up being rebuilt is because some dependency that rust
has does not match the ports tree (or options). For example,
the downloadable package being still based on use of an older curl
than is in the ports tree in my example. There is a time delay
between the ports tree update and a matching rust build being
available for download. During that time no download matching
the ports tree is available.

> Same version
> as on the pkg servers.

The same rust version number does not imply that the older rust
build is consistent with the ports tree that is being used in the
new build. rust (or other ports') version numbers to not carry
that much context information.

> I can't understand at the moment why the poudriere download-then-use
> works for a thing requiring gcc12 but not rust.

All it takes is for rust to depend on 1 or more ports that change
more often than any port that gcc12 depends on. There may also/instead
be a difference in how often rust is directly updated vs. how often
gcc12 is directly updated.

Please report historical examples of what poudriere is telling you
about that, such as:

[00:00:10] Deleting rust-1.72.0.pkg: missing dependency: curl-8.3.0_1

This is the way of figuring out what leads to the updates the most
often. It might lead to suggestions for the rust port for avoiding
depending on things that change more frequently if there are
reasonable alternatives.

> The longhand way of doing this without poudriere would be to install
> rust from the pkg.freebsd.org using pkg and then make install the port
> requiring rust from the ports tree. The last system I tried this on,
> the installed rust was used. Why not with poudriere?

Because the purpose of poudriere is to not do live updates with live
system materials that can-be/do-end-up inconsistent as they are
incrementally updated mid the overall build process. poudriere's
purpose is to be noticeably more reliable even if it takes extra
elapsed time or extra power, and so on. Its criteria are tied to
what is good for the official build servers' reliability. This
is what gets into the clean environment and the strict dependency
tracking as criteria.

The ports tree also has tools based on live-system-updates as port
builds happen and many folks prefer to use one of those. I have used
such in the past. I prefer the poudriere builds despite the
time/resource tradeoffs. I've never gotten into the type of nasty
problems that I on occasion got into before my poudriere use.

I do not claim people should use poudriere. But I have helped
someone recover from "live build" related problems repeatedly and
ended up recommending that they use poudriere and helped them get
started experimenting with it.

(I historically have used some platforms that ports-mgmt/synth did
not support so I've not experimented with that context in any
significant manor: I prefer to stick with a uniform tool set
across platforms.)

===
Mark Millard
marklmi at yahoo.com