Replies: 1 comment
|
I care about this sort of thing quite a lot, I have not yet done a deep dive into what versions of rustc we should support, but I am willing to make changes to support more platforms. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
I have been testing Bupstash since version 0.7.0 and been using it for "redundant" (and also some non-redundant...) backups ever since. I am using the Debian stable (currently Debian 11) OS and try to rely on the official repository as much as possible. Any programs that I install from beyond the repository, I attempt to create personal packages for that I can then compile and install on my Debian stable system. This is important to me because I use this scheme to keep the system reproducable and "self-contained" to some extent.
Trying to get Bupstash into this system has been a challenge because Rust -- like some other modern languages (Go, NodeJS ...) -- comes with its own package and dependency management that largely resides outside the Debian packaging system. Compiling Rust programs is almost never possible by "just" using the Debian repositories, it is almost always required to accept that dependencies will be downloaded by
cargoon demand.When attempting to create my own Debian package for Bupstash, I accept that dependencies are taken from
cargorather than the packaging system because it seems close to impossible to rely on the existent packages for them. However, it turns out there is another "blocker" for creating packages: Compiler dependencies. Compiler dependenceis are harder to solve because satisfying them would require me to not only permit the build system to automatically downloadcargodependenceis but also install a non-Debianrustc(and maybecargo) inside the build system (explicitly and in advance). So far, I have avoided having the build system depend on anything beyond Debian stablemainand this has the huge advantage of producing outputs that are almost guaranteed to work on any Debian stable system. It also keeps the build environment itself reproducible and self-sufficient.When installing
cargoandrustcfrom Debian and then attempting to compile the Bupstash master branch, I get the following errors:Basically it tells me that Debian's compiler is too old to compile the arrayvec dependency which is a transitive dependency due to bupstash -> blake3 -> arrayvec.
For
blake3one can work around this by downgrading the dependency to0.3e.g. as followsHowever, doing this results in the next build failure:
Here, an easy downgrade does not seem possible because when I experimented with "older"
zstd-safeversions I found none of them to both (1) compile and (2) provide all the API functions that Bupstash uses.I also found out that I can downgrade Bupstash itself from v0.11.0 (that I was using so far) to
v0.10.3which was prior to the introduction of the problematiczstd-safedependency. Then, using the above downgrade vorblake3, I can compile it using the Debian-providedrustcandcargo.So far, this is my "workaround" although it constraints me to stay on the old v0.10.3-tag (and re-create some backup repositories but that's a minor issue).
Now my question is as follows: Are such dependencies considered explicitly throughout the Bupstash development? Will future releases again need new compiler features ore is there some planned "stabilization" after which no new compilers will be needed anymore? Is it expected that future Bupstash versions will be packaged for Debian? (I have never created an official package, but currently it would seem to require that all dependencies are present in Debian for this to become possible...)
Thanks in advance and Kind Regards
Linux-Fan
All reactions