Can shadowsocks-libev come back to ports?

baaz

baaz

The shadowsocks-libev was removed a few months ago .
But it is still a widly used utility . It is still getting bugfixes and by no means is "Abandonware" .
Also It was realy faster to compile in ports, compared to the Rust version .

The old port Makefile still works, in fact before writing this I managed to install it by copying the folder from the old tree to the new .
But it would be nice if it can be installed from the ports "officially" .
 
You can use overlays using Poudriere but what's wrong with net/shadowsocks-rust? Just use the binary package if you think it's slow to compile?
 
diizzy said:
You can use overlays using Poudriere but what's wrong with net/shadowsocks-rust? Just use the binary package if you think it's slow to compile?
Click to expand...
The binary runs OK, but I like to install software from ports and the number of dependences made me think something was wrong with it .
 
Interesting. The deprecation notice says "Abandonware, no active development", but the link they provide in that notice says " Bug-fix-only libev port of shadowsocks", and has a commit this January. I'm no English scholar, but doesn't bug fixing count as active development?

Edit: Looks like the maintainer asked for the move to Rust. Fair nuff.
 
diizzy said:
The only dependencies it has is libzstd and the rust compiler so I don't really see the issue here
Click to expand...
What is it using for access to the sockets and encryption? Looking through the code I see a large number of bindings that the C version doesn't need.

Are these not dependencies? Hickery-DNS, log4rs, tokio and other crap? If you recurse through these dependencies alone, you end up with more dependencies than the entirety of Xorg.

Finally, if you look at the port log, the vast majority of entries are just "bumping" dependency revisions. For example this one bumped the following:
  • addr2line
  • anyhow
  • async-trait
  • autocfg
  • brotli
  • bytes
  • cc
  • clap
  • clap_builder
  • encoding_rs
  • flate2
  • futures
  • futures-channel
  • futures-core
  • futures-executor
  • futures-io
  • futures-macro
  • [...]
  • gimli
  • hashbrown
  • httparse
  • hyper
  • indexmap
  • ipnet
  • js-sys
  • [... and I am only 50% through the list...)
 
diizzy said:
It uses rust crates and rustls (aarch64, amd64, and i386)? You're mixing crates with build/lib/run dependencies which are not the same thing.
Click to expand...
No. I clearly stated dependencies. I can see them being downloaded as part of the process and compiled in. They are dependencies. Whether they are build, lib or run-time dependencies, crates or otherwise is not relevant and you know that. Why would it be?

Or are you saying that the Makefile is broken and shouldn't be downloading this stuff? Are you saying that a crate is not a dependency? I think most would disagree with that statement.
diizzy said:
You don't use shadowsocks if you want a "plain" socks server and current version of dante has a CVE that needs to be fixed.
Click to expand...
Firstly, I think we can safely assume that this number of dependencies dragged in by shadowsocks-rust makes it vulnerable to yet-undiscovered CVEs. So I don't think that you made an effective attempt to undermine dante as a solution.

Likewise, your attempt to justify the number of Rust dependencies by saying that dante is a "plain" socks server is also not effective, shadowsocks-libev is a good example of how this can be done with far fewer dependencies. I hope someone picks it up / forks it and the port is reinstated.

Apologies if this post comes across as confrontational, I just see sprawling Rust dependencies, and a lack of acknowledgement that this is a problem to be extremely damaging to good engineering these days.
 
Well, the ports tree works different? OP is asking about build/lib dependencies which aren't too different given that both share pretty much the same ones in the end. This also includes go(lang) ports which works in a similar fashion to rust ones.
Again, the main reason you're using shadowsocks is for obfuscation and encryption.
 
diizzy said:
Well, the ports tree works different? OP is asking about build/lib dependencies which aren't too different given that both share pretty much the same ones in the end.
Click to expand...
It is so disingenuous to say that some software doesn't have dependencies when you know it still pulls in 50+ dependencies but via an out-of-band process like crates.io/npm/pip/etc. Screw the almost 1000 lines in the distinfo eh? ;)

The ports tree really doesn't "work different". Most of us maintain ports here and can clearly see that there are ways to specify dependencies outside of the classic BUILD, RUN, LIB_DEPENDS. Dig into CARGO_CRATES for one, not too dissimilar to NODE_SCRIPTS.

diizzy said:
The only dependencies it has is libzstd and the rust compiler so I don't really see the issue here
Click to expand...
So as far as you are concerned, shadowsocks-rust only has 2 dependencies? Do you *truly* believe that statement to be correct and not intentionally misleading?

diizzy said:
This also includes go(lang) ports which works in a similar fashion to rust ones.
Click to expand...
Sprawling Go, Node.js dependencies are also terrible. Luckily those communities are way less viral.
 
Edit: There's actually only one build dep.
Yes, there's only build dependencies as far as the ports framework is concerned but if you're unwilling to accept that fact I can't change that.

```
make build-depends-list

/usr/ports/ports-mgmt/pkg
/usr/ports/lang/rust
/usr/ports/devel/cmake-core
/usr/ports/devel/gmake
/usr/ports/devel/pkgconf
/usr/ports/archivers/zstd
```

rust (rust pulls in curl which pulls in zstd) is the only "new" one, the rest are pulled in by reverse dependencies of cmake-core and others.
 
diizzy said:
Yes, there's only build dependencies as far as the ports framework is concerned but if you're unwilling to accept that fact I can't change that.
Click to expand...
Luckily we aren't talking about "as far as the ports framework is concerned". We are talking about actual dependencies.

So your comment mentioning libzstd and rust being the only dependencies was useless at best, completely wrong (and ignorant) at worst.

make build-depends-list is the wrong command to rely on for Rust-related ports. In future, also include make makesum && cat distinfo and save everyone some time dealing with your incorrect info. Other than that, keep up the good job@ :beer:.
 
kpedersen said:
Luckily we aren't talking about "as far as the ports framework is concerned". We are talking about actual dependencies.

So your comment mentioning libzstd and rust being the only dependencies was useless at best, completely wrong (and ignorant) at worst.

make build-depends-list is the wrong command to rely on for Rust-related ports. In future, also include make makesum && cat distinfo and save everyone some time dealing with your incorrect info. Other than that, keep up the good job@ :beer:.
Click to expand...
Given that post #4 refers to ports I'd assume we're talking about that but you seem to have another opinion about context.

If you want to look at a crate as dependency I guess every file you include in a C/C++ project would also count as a "dependency" (since you seem to adress any kind of file/including as one) which isn't really what you define as dependency as far as packaging goes (build, lib, run) and there's nothing "unbundle". Much of it is also covered by base which already contains uses C/C++ libraries and headers and it's a lot...

This seems to boil down to more your personal take on Rust, Go etc rather than the question at hand.
 
diizzy said:
If you want to look at a crate as dependency I guess every file you include in a C/C++ project would also count as a "dependency"...
Click to expand...
No. Not close. A binary dependency compiled from one or (likely a lot) more than one source file is obviously not the same thing as a source file you compile in your project.
 
Jose, the FreeBSD ports cargo.mk specifically refers to the CARGO_CRATES list as "static dependencies", so don't bother with whatever debate club nonsense diizzy@ is peddling. He is confused. They are dependencies; and a fsck(8)-tonne of them ;)

But for fun, do check out the librsvg2-rust port's Makefile.crates for a true cesspit of horror for such a simple library :D

There are more dependencies listed here than there are #includes in even the largest of software (and yes, of course the source code from crates.io dependencies gets compiled into binary code).

This is why no-one takes "Rust people" seriously. The language is good enough but the community is extremely ignorant when it comes to pulling in technical debt. Its not sustainable so try as they might to penetrate the market, everyone will always fall back to the C or C++ implementations eventually.

To be fair, it is almost certainly a good thing that the FreeBSD ports collection doesn't handle crates.io dependencies natively. Less mess when it all inevitably rots.
 
diizzy said:
Perhaps look at the official documentation?
Click to expand...
You read line 19 of cargo.mk? I think its quite clear about crates obviously being dependencies. No need to fight it.

Plus the relatively uncommon no_link attribute is irrelevant to this discussion. You think all the dependencies in shadowsocks-rust have that? You are scraping the bottom of your debate barrel at this point. Just stop haha.

diizzy said:
you seem to have very strong personal beliefs
Click to expand...
Agreed. My belief in striving for good engineering does indeed seem to be causing our opinions to differ. Spraying a project with careless amounts of dependencies (whilst refusing to acknowledge them as dependencies of course) certainly seems to be contrary to good engineering in my experience.

diizzy said:
No package repo handles crates individually because why would they in the first place?
Click to expand...
Exactly. Its not worth it. NPM, crates.io, PIP, CPAN, etc. All the same kind of stuff and should be handled as such. Only Perl *-p5-* ports seem to be the exception to this.

(But at least something good has come from this discussion. The shadowsocks-rust Makefile has been cleaned up a little. The absurd number of dependencies from Makefile has been isolated into Makefile.crates. You can try to hide them but we all know they are there, lurking...)
 
diizzy said:
Creates are not by default binaries
Click to expand...
Yes, they are.
A crate can come in one of two forms: a binary crate or a library crate. Binary crates are programs you can compile to an executable that you can run,such as a command-line program or a server...

Library crates don’t have a main function, and they don’t compile to an executable. Instead, they define functionality intended to be shared with multiple projects.
Click to expand...

Packages and Crates - The Rust Programming Language

doc.rust-lang.org doc.rust-lang.org

How do you create a library?
Let's create a library, and then see how to link it to another crate.

In rary.rs...

$ rustc --crate-type=lib rary.rs
$ ls lib*
library.rlib
Click to expand...

Creating a Library - Rust By Example

Rust by Example (RBE) is a collection of runnable examples that illustrate various Rust concepts and standard libraries.
doc.rust-lang.org doc.rust-lang.org

What does rustc do?
Compilers take your source code and produce binary code, either as a library or executable.
Click to expand...

What is rustc? - The rustc book

doc.rust-lang.org doc.rust-lang.org

I can see the cause for confusion. The Rust documentation geniuses decided to shorten "binary executable" to just "binary." When someone tells you there are two kinds of things: "binaries" and "libraries", I can see how you would conclude that libraries are not binaries. It's a terribly worded paragraph.
 
kpedersen said:
You read line 19 of cargo.mk? I think its quite clear about crates obviously being dependencies. No need to fight it.

Plus the relatively uncommon no_link attribute is irrelevant to this discussion. You think all the dependencies in shadowsocks-rust have that? You are scraping the bottom of your debate barrel at this point. Just stop haha.


Agreed. My belief in striving for good engineering does indeed seem to be causing our opinions to differ. Spraying a project with careless amounts of dependencies (whilst refusing to acknowledge them as dependencies of course) certainly seems to be contrary to good engineering in my experience.


Exactly. Its not worth it. NPM, crates.io, PIP, CPAN, etc. All the same kind of stuff and should be handled as such. Only Perl *-p5-* ports seem to be the exception to this.

(But at least something good has come from this discussion. The shadowsocks-rust Makefile has been cleaned up a little. The absurd number of dependencies from Makefile has been isolated into Makefile.crates. You can try to hide them but we all know they are there, lurking...)
Click to expand...
You seem to misunderstand parts of the ports tree, there's no hiding going on at all, it's common practice and documented here: https://docs.freebsd.org/en/books/porters-handbook/book/#splitting-long-files
p5-* are CPAN ports (not all of course but the majority), https://docs.freebsd.org/en/books/porters-handbook/book/#using-perl
By pip I guess you mean pypi which many of the Python ports is using as MASTER_SITES / is used for packaging (just grep the tree).
 
kpedersen: can you stop your anti rust propaganda? It's getting irritating.
Not a single post of yours were to help the OP with his problem but to bitch about rust.
 
You must log in or register to reply here.
Back
Top