The current versions of terra and sf do not support direct reading of 7zip compressed files, because GDAL does not support it yet. But it seems that this feature will be included in GDAL version 3.7.0, scheduled for May 1, 2023 (https://github.com/OSGeo/gdal/milestone/42). Knowing that terra and sf are currently using GDAL version 3.4.1, released on 12/27/2021, should we expect that support for direct reading of 7zip files will be available in terra's or sf's CRAN binary packages a year or so after its inclusion in GDAL? I have no idea how GDAL is integrated with terra or sf, so my question may be naive or poorly phrased. Thanks in advance.
It depends on your operating system, and how you install.
On Windows we depend on what is included in Rtools. Rtools tends to be up-to-date. I would expect a delay in the order of months. But as you point out it more than 12 months now. Rtools was just updated to GDAL 3.6.0 (and it should be updated again soon as that version of GDAL was retracted). There can be an additional delay if a new version of Rtools is not yet used at CRAN (or only for R-devel), so it can sometimes help to install from source.
On Linux you can install any version of GDAL you want, if you have permission to do so. The defaults on some Linux systems are terribly old. On Ubuntu it helps a lot to use the ubuntugis-unstable repository (see instructions). If you are on Ubuntu and use r2u, then it depends on what they use.
On OSX you may use the CRAN binary or GDAL install yourself from source or install it with "brew". You can see what is used for CRAN here. I think the lag in the GDAL version of the CRAN binaries typically is also only in the order of months. "brew" seems to keep very good track of GDAL updates.
Related
The usual recommendation for handling the dependencies on Linux is by using the distro's package manager.
The good part of this approach is that you can reuse the basic set of libraries configured, tested, and updated for your system.
The bad part is that there are many distros with different package managers, and you probably have to support several of them. Users of not-so-popular distros have to work on their own to set up the dependencies.
The worst part is, when talking about games, some game distribution platforms ban the developer from using package files for installation.
Quoting itch.io,
.deb and .rpm packages (Oh no tier)
These are ignored when looking for uploads - it'll appear as if your app wasn't available on Linux at all.
Do not use these.
To not use the package manager, one way is to build the app on a reasonably old system, like Debian oldstable or the Steam Runtime (based on Ubuntu 12.04), and distribute the final software by copying the shared libraries depended upon.
My question is which shared libraries should be copy-distributed in this stage.
Do I have to ship libc? If I don't, is it guaranteed that newer versions of libc has backwards compatibility with older versions of libc?
Can I just be safe and ship all the dependencies? Will it work on most systems despite being a bit heavy?
If that's not a solution, which shared libraries should I include and which not?
Do I have to ship libc?
For reasons explained here, it is nearly guaranteed that your libc.so.6 will not be compatible with the system ld-linux.so (the path to system ld-linux.so is baked into your binary).
You could however use a shell wrapper to avoid this problem. Something along the lines of:
#!/bin/bash
TOP=/path/to/your/install
exec -a "mygame" "$TOP/lib64/ld-linux-x86-64.so.2" --library-path "$TOP/lib64" "$TOP/bin/mygame"
If I don't, is it guaranteed that newer versions of libc has backwards compatibility with older versions of libc?
Yes, GLIBC backward compatibility guarantees exactly that: you could copy a binary from a system of 10 or 20 years ago, and it will run on a freshly installed latest distribution1.
which shared libraries should I include and which not?
Note that by distributing GPL software you assume certain obligations. Talk to your lawyer if you plan to do that.
1There have been a few bugs about 15 years ago where this backward compatibility was broken in some specific cases, but you are unlikely to run into them.
At the time of writing this question, Ubuntu 22.04 is almost out. I am curious about how fast the developers will migrate from older versions (potentially from 18.04 LTS) to the new LTS. This is important for me to decide which Ubuntu version I should target with my application.
The best would be some statistics about the usage of the different Linux distros and versions, potentially with time scale. There are a few charts and list out (e.g., https://distrowatch.com/dwres.php?resource=trending) but I could not find any statistics that go down to the distro's version level.
What is the best or "official" source to get this information from?
This maybe a dumb question but can someone explain how to install Berkeley for SICstus on Windows? This is my last resort
The entire Oracle site for Berkeley DB seems broken, with many broken links. Also, there are no longer any installers, and only the latest version of the source code. Their site has been that way for over a year. I do not know what happened.
In the mean time, I was able to download the Windows installers by first creating a free Oracle Account, logging in, and then using the links https://download.oracle.com/otn/berkeley-db/db-6.2.38_64.msi and https://download.oracle.com/otn/berkeley-db/db-6.2.38_86.msi (found via the Wayback Machine). These versions should be compatible with SICStus Prolog 4.6 on Windows.
I'm looking for some advice on how to properly handle versioning when managing a distro using Yocto.
I have several embedded systems in production and have to rely on a third party to apply updates. Updates include one or more .ipk packages that get installed via opkg. I have no control over when the third parties apply the update(s) I send them. This introduces the issue I am trying to find a solution to. The systems are likely to be in various different states as some updates are applied and others are not. Is there a common solution to tell what state a system is in?
One problem I'm not clear on is how ensure the embedded system has certain updates applied before applying further updates. How do distros such as Ubuntu or Redhat handle this? Or do they?
Ubuntu and RedHat have a remote repositories. The systems have a internal list of installed packages. When you update the repository you get a new list of packages. You can then compare this list of installed packages against the new package list and install them. This is basically done with apt-get update && apt-get upgrade and the yum equivalent.
Yocto actually supports rpm and deb package format and their remote repositories. I am not familiar with opkg and if they have the option of a remote repository.
When I implemented a system I narrowed it down to the following options:
have a repository (deb and rpm definitely work here)
have a version package
using images
Version packages have the big disadvantages since you have to get your own logic on which packages to install. But you can require that version-1.deb needs software-v2.deb and tool-v1_5.deb. That works well with you own software but is a big manual overhead for the entire Yocto package stack.
Repository would be the usual way such as: apt-get update && apt-get -y upgrade. Works well and easy, but lacks also a risk free path to newer Yocto version.
The image way is more complicated and depends on your used hardware, size of image and transfer of the image. If you have a huge image and a slow network you might not want to do this. Basically you push your new image (or automatically pull it based on a version) d push it then to the device. The device dd's it to a secondary partition and then you flip the bootload to use the other partition. Depending on bootloader and/or hardware you can automatically flip back in case the partition you booted in is broken. Helpful for remote systems. Advantage is: you can also easily upgrade the entire OS without manually picking versions. And you can have (automatic) fail-over.
I am using a shared C library on Linux that is distributed in binary form. The problem is that the dependencies are set to require exactly the versions available on the development machine. For example, each release requires the (at the time) latest glibc and only the exact version of libreadline on their system.
I have contacted the developers and they don't know what to do about this. As far as I can tell, they are not consciously using the latest features, so the library should continue to work with older dependencies. I think they are using gcc on Linux, but they are also using a complex make system to control other compilers to build for Windows and Unix.
How and to what extent can you manage the build process so that a library requires dependencies just of a sufficient version and will also accept later versions?
This was a related question.
Edit: To be clear, I want to know how to build programs so they will accept dependencies with a specific version number or later numbers. Whether the developers compile it or I do, I want to be able to distribute a binary that does not require exactly the versions of dependencies present in the build environment.
Edit 2: After rephrasing the question, I realized this has been covered many times before. Some of the best Q&A:
Deploying Yesod to Heroku, can't build statically
Compile with older libc
Linking against an old version of libc
How can I link to a specific glibc version?
It's not very confidence inspiring. They should be building on a stable baseline release, it could just be a virtual install. Some versions of Linux, copy a build environment so packages aren't linked to updated library versions.
The openSUSE build service, lets devolopers build binary packages, for a wide variety of http://openbuildservice.org/about/
IIRC readline is a GPL program and checking at http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html#Availability suggests it is GPL v 3 so they may be in violation of the GPL, if they are using libreadline functions and should provide you with the source to their library. I am not sure if you are meaning rpm/apt package dependencies, or their library is actually calling libreadline.
You can always extract files from rpm or apt packages, if necessary so avoiding software manager issues, caused by poor packaging.