Date: Sat, 21 Oct 2023 21:21:33 -0700 From: Mark Millard <marklmi@yahoo.com> To: void <void@f-m.fm> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: rust 1.72.0 in poudriere-devel keeps getting rebuilt Message-ID: <42EF6FE9-AF6B-46A1-A4EF-86A1EC74DABF@yahoo.com> In-Reply-To: <d08fb10a-62c6-4202-a799-c9548068c98c@app.fastmail.com> References: <d94d5b82-1d7c-4c8f-b846-b7b7cf94e996@app.fastmail.com> <057159E4-7E05-49A3-8520-3E2815C4A6A0@yahoo.com> <d08fb10a-62c6-4202-a799-c9548068c98c@app.fastmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42EF6FE9-AF6B-46A1-A4EF-86A1EC74DABF>