Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cache breaks compatibility #2821

kodebach opened this issue Jul 12, 2019 · 3 comments


Copy link

commented Jul 12, 2019

I'm not sure whether this one can be solved, but I think the cache currently breaks backwards compatibility.

While working on #2809 I tried to add a test case that does the following:

  1. Compile all the libs (i.e. all the *.so.0.8.26 files in $BUILD_DIR/lib)
  2. Download the latest release from
  3. Extract and build this release
  4. Copy the libs compiled in step 1 into the build directory of step 3
  5. Run the tests of the latest release

A lot of the test cases fail, becaue cannot be found.

Compiling with -DPLUGINS="ALL;-EXPERIMENTAL;-cache" in step 1 solves the problem, so it is definitely the cache that is at fault here.

Here is the script I used for testing (it is not a proper test case yet):



SCRIPTS_DIR=$(dirname "$0")

BASE_DIR=$(mktemp -d)





trap 'exit $?' ERR
mkdir "$BUILD_DIR"

LIBS=$(cmake -L -S "$SOURCE_DIR" -B "$BUILD_DIR" | grep -Fi "ADDED_LIBS" | cut -d '=' -f 2)
LIB_TARGETS=$(echo "$LIBS" | tr ';' ' ')

cd "$OLD_DIR"

curl "$RELEASE.tar.gz" --output "$BASE_DIR/release.tar.gz" --silent
tar -xzf "$BASE_DIR/release.tar.gz" -C "$BASE_DIR"
mv "$BASE_DIR/elektra-$RELEASE" "$BASE_DIR/release"



make -C "$RELEASE_BUILD_DIR" run_all
cd "$OLD_DIR"
@kodebach kodebach referenced this issue Jul 12, 2019
1 of 14 tasks complete

This comment has been minimized.

Copy link

commented Jul 20, 2019

I'm pretty sure this is caused by how I detect that the cache is compiled.

// TODO: this is a poor way of detecting whether cache is compiled, but simply
// matching against cache might fail because of other plugins (e.g. "cachefilter")
if (strstr (ELEKTRA_PLUGINS, ";cache;") != NULL)
ksAppendKey (config, keyNew ("system/elektra/globalplugins/postgetcache", KEY_VALUE, "cache", KEY_END));
ksAppendKey (config, keyNew ("system/elektra/globalplugins/pregetcache", KEY_VALUE, "cache", KEY_END));

However, according to @markus2330 in the long run it should be default and always mounted, similar to list. It should work on all POSIX compliant systems. I think this can definitely be solved. A trivial solution would be to silently fail (simply not mount it) on non-POSIX systems.


This comment has been minimized.

Copy link

commented Jul 31, 2019

Is this really a compatibility problem or some other issue? I cannot reproduce it. If I install "elektra-tests_0.8.26-1_amd64.deb" with libelektra from master, I do not see any warnings about the cache and kdb info cache works (there are many other problems, though: ini, yajl, reference, ... fail).

@kodebach thank you for the script. What is the difference between trap 'exit $?' ERR and set -e?

@mpranj yes, in general I am very open to make mmap to a fundamental part of Elektra. At the moment, however, it seems like it does not change the semantics anyway. If we can keep Elektra working also without mmap it would be nice (for constrained systems where the 50kB of the mmap plugin might be a problem).

So, as discussed in #2831, we can simply let mount.c succeed silently if the cache plugin was not found. Only after a user explicitly activated the cache, she should get a warning.

If we make the mmap cache a required part of Elektra, we should fail if the cache is not present (both in CMake and at run-time).


This comment has been minimized.

Copy link
Contributor Author

commented Jul 31, 2019

What is the difference between trap 'exit $?' ERR and set -e?

Not sure that would set -e preserves the exit code, but the actual reason why I used a trap is that I had additional debugging code instead of exit $? at some point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.