We're talking about the crates listed in the port Makefile, they'are just tarball:
file /usr/ports/distfiles/rust/crates/addr2line-0.21.0.crate
/usr/ports/distfiles/rust/crates/addr2line-0.21.0.crate: gzip compressed data, was "addr2line-0.21.0.crate", max compression, original size modulo 2^32 179200Yep, which is why I mentioned it is the exception.
I've clearly stated its the dependencies (whether NPM, PIP, crates.io) that is ultimately the issue multiple times throughout this thread. If a decent software got replaced with some Node.js crap with a daft amount of NPM cruft, I would have also suggested the OP to ditch it. As for propaganda, what have I stated that was incorrect exactly?
Nonsense, you can see my third post even got a "thanks" react from the OP.
Indeed. And why was it a long file again? Perhaps all the daft crates.io dependencies? Does that not highlight that there is something not quite right? Purely from an observation standpoint.
I believe everyone is referring to the fact that they get compiled into a binary along with the port. They are a dependency. If they weren't they wouldn't be there right? They are not all no_link macros as was incorrectly alluded to further up in the thread.
Out of 2 sentences, one was a snarky comment about the rust ecosystem, was it really necessary?
Yeah I'm pretty sure windows_x86_64_msvc-0.48.5 gets compiled in the ports.
Yes, if people start replacing decent software with this kind of stuff, it really should be highlighted. If there weren't alternatives, I feel it would even be worthy of a bug/defect report to get the bug-fix libev port re-instated.
As a rebuttal, that was quite a weak attempt at suggesting that there are not in fact a daft amount of dependencies involved in shadowsocks-rust. Run a build of that port, anyone can see the vast amount that get compiled in. You can then try the previous approach of attempting to overlook them as dependencies based on a technicality of how the ports collection labels things but this is also not very useful as part of the discussion.
I ask again, which specific part of what I have stated was incorrect? Perhaps its not BS, you just personally don't like it?
Hmm, all I can suggest is for your own software, possibly explore graphics/librsvg2.
Nah, he was just continuing to be awkward and defensive. Everyone (especially a port maintainer) knows that compiled libraries are also commonly referred to as binaries. Regardless of C, C++, Rust, etc. But frankly, even if it was statically linked, a header-only MACRO or build script, it would still be a dependency.
Well, at least you are able to aknowledge the issue.
Heh, nice try. Unless you are able to be more specific. Perhaps just stop.
If the incorrect use of dependencies doesn't shock you and you don't see an issue, then good luck to your employer.
Read my own posts? Seems kind of odd as a recommendation. I believe, you were just about to point out where something I said earlier in the thread was incorrect...? No?
Try
DEFAULT_VERSIONS+=librsvg2=legacy in your make.conf.Let's re-read what diizzy said "Creates(sic) are not by default binaries" (emphasis mine.) So you're saying the Rust documentation for beginners is giving examples of doing things that are not the default? Also, there's no possible way a tarball could contain any binaries, right? That's like saying Java .jar files are just zip files.
The irony!
again this is your personal opinion, it's an issue for you and maybe others but not an issue for everyone, is it a concept too hard for you to understand?
Its a case of "help us, help you". By clearly trying to explain why reducing dependencies is important, everyone as users will end up with a better software. Either my explaination is failing or their comprehension is failing.
That's a good point. C and C++ have header-only libraries (you should know, you've written at least one!) No C/C++ programmer would claim they're not dependencies because they're not pre-compiled, though.
Maybe myself, maybe others. So perhaps its something for you to consider then? Rather than just denying that crates are dependencies... That was a pretty poor compromise was it not?
Exactly. Dependencies should always be considered. Including a header from POSIX or even in base might be a "free" dependency. But including something from i.e the glm maths library or a crate is certainly not a free dependency. Apparently being able to identify such dependencies is not so easy for some people. I suppose I didn't realize that so many struggle to analyze software in this way. Disappointing.
ever heard of automatic spellcheck? I'm not saying anything, you are. A crate in a FreeBSD port Makefile just represent a tarball needed to compile the port, and yes good news for you a tarball can have whatever file type in it.
I never said it was not a dependency.
But it's not just an opinion. How many times on this forum have you heard people suffering in dependency Hell? DLL Hell in the Windows user community? Dependencies are a double-edged sword. You don't have to re-invent the wheel every time, but you're dependent on an upstream that might go dead, or otherwise go off the deep end in many other ways.
www.theregister.com
What are you using for a browser?
librewolf, why? This port is required by both gtk30 and gtk40 so it's basically unavoidable if you're using a graphical environment.
So you mean, reinvent the wheel so that we don't have to bring a xyz dependency?
Thanks, I use Firefox, which drags in Rust. I'll give Librewolf a try.