On Sat, 7 Jun 2025 08:18:36 -0700 Pete Wright <[email protected]> wrote:
> > > On 6/7/25 7:46 AM, Mathieu Arnold wrote: > > On Sat, Jun 07, 2025 at 04:36:34PM +0300, Gleb Popov wrote: > >> On Sat, Jun 7, 2025 at 4:19 PM Mathieu Arnold <[email protected]> wrote: > >>> > >>> Hi, > >>> > >>> I am sorry but I do not understand, you are basically re-inventing `pkg > >>> install rust`, but from within a port, it makes little sense. > >> > >> It makes sense for Poudriere users that often have to recompile > >> lang/rust, but would like to avoid that. > > > > Well, I'm not sure this needs to be spelled out, but, well, people who > > decide to build their own ports have to, well, build their own ports. > > > > If they don't want to build their own ports, they should be using the > > packages we provide, or at least use the poudriere option that will > > fetch the packages instead of building them. > > > > But adding binary packages to the ports tree makes absolutely no sense. > > > > IMHO there should be a middle ground here, our rust port contains over > 40k html files and documentation. this seems wild that we just force > people to deal with that rather than trying to improve things for a > wider set of users. maybe the answer is a no-doc version of the package? > > $ pkg list rust | grep html | wc -l > 44447 > $ > > for low power vm's or systems its super wasteful to force installation > of so many small files. rust/cargo is slow enough, but having to wait > ages for rust itself just makes things needlessly more painful. > > -pete > > > -- > Pete Wright > [email protected] It seems splitting out docs to something like misc/rust-docs[-nightly] and lang/rust[-nightly] to be slimmed down is the way to go? And if possible, does splitting out fundamental libraries and code generator, making them independent port, could decrease needs for bumps? Possibly it would cause builtin default compile option to be --crate-type=dylib or --crate-type=cdylib on FreeBSD ports. Currently consumers of lang/rust are almost always bumped when lang/rust is updated, but quite unfortunately, lang/rust has too huge consumers like www/chromium. Need for bumps should be minimized, to really, really actually mandatory cases only that the upgrade causes already-compiled objects to stop working, or generated codes are assured to be insecure. Or limit upgrading of lang/rust to be the same timing that any of huge consumers is upgraded. (For example, upgrade lang/rust at the SAME COMMIT with www/chromium, devel/electron*.) -- Tomoaki AOKI <[email protected]>
