SoundScapeRenderer / ssr

Main source code repository for the SoundScape Renderer
http://spatialaudio.net/ssr/
GNU General Public License v3.0
134 stars 53 forks source link

Unable to upgrade package to 0.6.1 due to issues with asdf-rust #390

Open dvzrv opened 8 months ago

dvzrv commented 8 months ago

Hi! :wave:

When trying to upgrade the Arch Linux package to 0.6.1 I noticed that now a new library is required: https://github.com/AudioSceneDescriptionFormat/asdf-rust

checking for asdf... no
configure: error: dynamic-asdf (dynamic ASDF scenes) not available! Use --disable-dynamic-asdf to deactivate.

Unfortunately I was not able to build it due to open issues: https://github.com/AudioSceneDescriptionFormat/asdf-rust/issues

This currently blocks me from upgrading. Are downstreams expected to disable the new feature (it is on by default)?

Relatedly, why was this added in a patch level release and not a feature release? :)

mgeier commented 7 months ago

Sorry for my non-response on those asdf-rust issues, I'll get to it eventually ...

I don't really know how packagers should handle this, but I guess providing a crates.io package won't suffice (or even help at all). The problem is that the SSR doesn't consume the Rust crate but the dynamic C library built with cargo-c, see https://github.com/AudioSceneDescriptionFormat/asdf-rust/blob/master/README.md#building-the-c-api.

So I guess the package build process would need to install and use cargo-c to build the ASDF library?

Do you know of any existing packages which provide a C library implemented in Rust?

Are downstreams expected to disable the new feature (it is on by default)?

Ideally not, but IIRC @umlaeute did it for the Debian package. If it's too much hassle, it's fine to disable it.

Relatedly, why was this added in a patch level release and not a feature release? :)

I'm not sure, I guess I wasn't spending too much thought on this. Maybe the question is which versioning scheme are we using?

I kinda got used to how Rust packages tend to do it: the scheme is different for 1.0+ releases and for 0-based versions. For 0.x.y, bumping x means a breaking change and y means a non-breaking change. See https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-cratesio

Since nothing was changed, only features were added, I considered 0.6.1 non-breaking. Strictly speaking, not auto-starting the JACK server should be considered a breaking change, but I have the feeling that it solves more problems than it creates.