search

vi / websocat

Command-line client for WebSockets, like netcat (or curl) for ws:// with advanced socat-like functions
MIT License
6.72k stars 257 forks source link

Update cargo.lock for the v1.10.1 release #159

Open oliv3r opened 2 years ago

oliv3r commented 2 years ago

The Alpine package explicitly uses the --locked argument to ensure the proper dependencies. However, with the v1.10.1 release this fails:

>>> websocat: Unpacking /var/cache/distfiles/websocat-1.10.1.tar.gz...
    Updating crates.io index
error: the lock file /workdir/src/websocat-1.10.1/Cargo.lock needs to be updated but --locked was passed to prevent this
If you want to try to generate the lock file without accessing the network, remove the --locked flag and use --offline instead.
>>> ERROR: websocat: build failed

Dropping the lock fixes the build, which implies that the lock file would need to be updated.

oliv3r commented 1 year ago

@vi any update on this?

vi commented 1 year ago

For FreeBSD I supplied additional Cargo.lock.freebsd for similar reasons.

Can Alpine package do mv Cargo.lock.freebsd Cargo.lock before building with --locked?

Legacy Cargo.lock is needed to be able to build Websocat on older Rust versions (e.g. on Debian using distro rustc and cargo), so I supplied two lockfiles.

oliv3r commented 1 year ago

Hey @vi, yeah sure we can do that (just did). Is this expected to be done always? Or only under certain conditions? Can we codify these conditions?

vi commented 1 year ago

Maybe next Websocat release should have modern Cargo.lock by default and legacy-friendly one under alternative name, so if Cargo.lock.freebsd is absent then it should not fail the build, just use usual Cargo.lock instead.

oliv3r commented 1 year ago

Thanks @vi, for now, I'll do this, and next release we can remove this work-around again.

oliv3r commented 1 year ago

Lets keep this issue open as a reminder, so we can close it when this is actually resolved.

anthraxx commented 1 year ago

I've run into the same issue for Arch Linux packaging. I'd also propose to simply switch the Cargo.lock and provide a Cargo.lock.legacy instead if such a file is required :cat:

vi commented 1 year ago

Yes, that's what I already done when I started to prepare for Websocat v1.11 (before my attention moved elsewhere). It will both carefully manually updated MSRV-preserving Cargo.lock.legacy (allowing to build Websocat with modern-ish OpenSSL on Debian Stable with system toolchain) and usual Cargo.lock with reasonably modern dependencies.

Note that Websocat v1 branch may also gain maximum supported Rust version, as some of unavoidably outdated dependencies may depend on undefined behaviour that was fortunate to work before, but now becoming definitely broken.