Libelektra: cache: sistema de exportação kdb

Claro, por que não? Ele também exporta versão e outras coisas não úteis para importação. Você pode adicionar --without-elektra para evitar a exportação dessas peças.

Para o gravador de shell, eu também esperaria que apenas a parte fornecida fosse salva e restaurada.

Claro, por que não?

kdbSet remove de alguma forma? Parece errado serializar essas chaves, quando elas são codificadas por meio de uma parte especial das funções de obtenção do plugin ...

Para obter informações sobre a versão, o kdbSet verifica se eles são idênticos e ignora o kdbSet se forem. Caso contrário, um erro será gerado.

Para módulos (iirc), não há kdbSet, então as chaves a serem definidas são simplesmente ignoradas. Iirc, o plugin "constantes" tem o mesmo comportamento. Geralmente é montado em system / info / elektra, então não em system / elektra. Talvez devêssemos mudar isso para tornar --without-elektra mais útil?

Mas de qualquer maneira: ambos os comportamentos (ignorar e verificar as chaves idênticas) não devem prejudicar uma importação.

Portanto, para a situação atual do Elektra bastante instável, faz todo o sentido: as importações do sistema / elektra são rejeitadas, a menos que a versão seja idêntica. Para evitar esse erro, --without-elektra pode ser passado.

Depois do 1.0, podemos ficar mais relaxados e aceitar as importações das versões 1.0 ou superior do Elektra. ( @mpranj o que você acha?)

O texto precisa ser adaptado então, atualmente é:

kdb import system < sys
Sorry, module kdb issued the error C01320:
Interface: Read only plugin, 'kdbSet' not supported but the key system/elektra/version/constants/KDB_VERSION_MICRO (expected system/elektra/version/constants/KDB_VERSION_MICRO) was tried to be modified to '1' (expected '2')

De qualquer forma, sua pergunta dá uma ideia sobre como podemos melhorar a documentação de --without-elektra . A ideia de --without-elektra no contexto de importação / exportação é:

1. todos os internos da Elektra são exportados, mas também temos a verificação de versão para não bagunçar o Elektra.
2. você não importa / exporta internos do Elektra, portanto, a versão do Elektra não importa (apenas a versão do plugin de armazenamento importa)

Depois de 1.0, podemos realmente ficar mais relaxados

Eu concordo com as sugestões.

Como @kodebach mencionou, é de alguma forma estranho que isso tenha aparecido agora em # 3115 e não tenha aparecido antes. Embora a adição de --without-elektra provavelmente devesse estar lá em primeiro lugar para backup e restauração, ainda parece que o PR mudou algum comportamento.

@kodebach você ativou o cache novamente para esses testes? Eu gostaria de esperar o resto do PR ser feito para que eu possa corrigir o mmapstorage e o cache. Eu vi esses erros / semelhantes ( Postcondition of backend was violated: drop key [...] not belonging to [...] ) enquanto o cache não foi implementado corretamente.

você ativou o cache novamente para esses testes?

Sim, o cache está totalmente ativado.

para que eu possa corrigir o mmapstorage e o cache

mmapstorage já funciona. Acontece que eu tinha um key vez de ukey algum lugar.

O cache também parece funcionar, além do problema com o teste de desmontagem global. A última vez que verifiquei, o erro não aconteceu quando o cache não foi compilado.

Eu mudei partes de kdbGet , elektraCacheGet e funções relacionadas. É provável que quebrei algo, mas como as coisas que mudei provavelmente terão que ser alteradas novamente após o # 2969, não acho que você precise dar uma olhada agora.

OK. Eu sugiro que se o cache + mmapstorage causar problemas você simplesmente mantenha-o desativado até o final e nós o ativamos e adaptamos então.

O PR é uma mudança bastante fundamental, então será muito mais fácil se você não ficar preso por causa de algum comportamento de cache quebrado. Quando estiver basicamente pronto, basta ativar o cache novamente e enviar um ping para que eu possa dar uma olhada e consertar os restantes.

@mpranj :

Não consigo reproduzir nada semelhante no mestre atual. Não posso fazer muito lá, a menos que alguém saiba como reproduzi-lo lá, mas suspeito que não esteja presente no master.

No ramal de # 3115, recebo os erros conforme descrito. @kodebach devo ir lá e tentar consertar as coisas relacionadas ao cache além de suas alterações ou é muito cedo para trabalhar nisso? Quão chato é realocar o branch do master atualmente (plugin pré-backend)?

Acho que não vale a pena trabalhar no # 3115 até que o # 2969 e os PRs relacionados sejam mesclados. Depois disso, irei rebase e tentarei finalizar o PR. Eu gostaria de rebase o mínimo possível, porque você basicamente tem que verificar todos os commits para qualquer coisa que dependa da sintaxe de nomes-chave para garantir um rebase adequado.

Se quiser, é claro que você pode procurar o bug na versão atual do PR. No entanto, pelo que me lembro, tentei fazer isso em master antes de criar o problema, então talvez ele tenha sido corrigido nesse ínterim.

Acho que não vale a pena trabalhar no # 3115 até que o # 2969 e os PRs relacionados sejam mesclados.

Ok, obrigado! Então, vamos esperar e verificar esse problema depois que os PRs relacionados forem mesclados!

É possível marcar problemas de alguma forma que eles estão esperando por alguns PRs? Eu mudei o título por enquanto.

Na verdade, consegui reproduzir isso em master hoje. Especificamente, eu construí scripts/docker/fedora/32/Dockerfile (tecnicamente de # 3447, não de master , mas o arquivo é o mesmo e completamente autônomo). Então comecei um contêiner com

docker run -it -w /home/jenkins elektra-fedora-32:latest

e dentro do contêiner correu as seguintes linhas:

git clone https://github.com/ElektraInitiative/libelektra
cd libelektra && mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Debug -DKDB_DB_SPEC="$PWD/config/spec" -DKDB_DB_SYSTEM="$PWD/config/system" -DKDB_DB_USER="cdbg-1/.config" -DCMAKE_INSTALL_PREFIX="$PWD/install" -DINSTALL_SYSTEM_FILES=OFF -DENABLE_DEBUG=ON -DENABLE_LOGGER=ON -DCMAKE_EXPORT_COMPILE_COMMANDS=TRUE -DPLUGINS="ALL;-lua;-ccode;-tcl" -DBINDINGS="ALL" -DCOMMON_FLAGS="-Werror"
make -j 24
bin/kdb export system toml

A saída do último comando foi:

elektra.modules.cache = "cache plugin waits for your orders"
elektra.modules.cache.exports = ""
elektra.modules.cache.exports.close = "(binary)"
elektra.modules.cache.exports.get = "(binary)"
elektra.modules.cache.exports.open = "(binary)"
elektra.modules.cache.exports.set = "(binary)"
elektra.modules.cache.infos = "Information about the cache plugin is in keys below"
elektra.modules.cache.infos.author = "Mihael Pranjic <[email protected]>"
elektra.modules.cache.infos.licence = "BSD"
elektra.modules.cache.infos.metadata = ""
elektra.modules.cache.infos.needs = ""
elektra.modules.cache.infos.placements = "pregetcache postgetcache"
elektra.modules.cache.infos.provides = ""
elektra.modules.cache.infos.recommends = ""
elektra.modules.cache.infos.status = "maintained unittest shelltest specific global"
elektra.modules.cache.infos.version = 1
elektra.modules.dump = "dump plugin waits for your orders"
elektra.modules.dump.config.needs.fcrypt.textmode = 0
elektra.modules.dump.exports = ""
elektra.modules.dump.exports.get = "(binary)"
elektra.modules.dump.exports.serialise = "(binary)"
elektra.modules.dump.exports.set = "(binary)"
elektra.modules.dump.exports.unserialise = "(binary)"
elektra.modules.dump.infos = "Information about the dump plugin is in keys below"
elektra.modules.dump.infos.author = "Markus Raab <[email protected]>"
elektra.modules.dump.infos.licence = "BSD"
elektra.modules.dump.infos.metadata = ""
elektra.modules.dump.infos.needs = ""
elektra.modules.dump.infos.placements = "getstorage setstorage"
elektra.modules.dump.infos.provides = "storage/dump storage dump"
elektra.modules.dump.infos.recommends = ""
elektra.modules.dump.infos.status = "productive maintained conformant unittest tested nodep -1000 default"
elektra.modules.dump.infos.version = 1
elektra.modules.list = "list plugin waits for your orders"
elektra.modules.list.exports = ""
elektra.modules.list.exports.addPlugin = "(binary)"
elektra.modules.list.exports.close = "(binary)"
elektra.modules.list.exports.deferredCall = "(binary)"
elektra.modules.list.exports.editPlugin = "(binary)"
elektra.modules.list.exports.error = "(binary)"
elektra.modules.list.exports.findplugin = "(binary)"
elektra.modules.list.exports.get = "(binary)"
elektra.modules.list.exports.mountplugin = "(binary)"
elektra.modules.list.exports.open = "(binary)"
elektra.modules.list.exports.set = "(binary)"
elektra.modules.list.exports.unmountplugin = "(binary)"
elektra.modules.list.infos = "Information about the list plugin is in keys below"
elektra.modules.list.infos.author = "Thomas Waser <[email protected]>"
elektra.modules.list.infos.licence = "BSD"
elektra.modules.list.infos.needs = ""
elektra.modules.list.infos.placements = "pregetstorage procgetstorage postgetstorage postgetcleanup presetstorage presetcleanup precommit postcommit prerollback postrollback"
elektra.modules.list.infos.provides = ""
elektra.modules.list.infos.status = "unittest nodep libc configurable global"
elektra.modules.list.infos.version = 1
elektra.modules.resolver_fm_hpu_b = "resolver_fm_hpu_b plugin waits for your orders"
elektra.modules.resolver_fm_hpu_b.constants = ""
elektra.modules.resolver_fm_hpu_b.constants.ELEKTRA_VARIANT_BASE = "fm"
elektra.modules.resolver_fm_hpu_b.constants.ELEKTRA_VARIANT_SYSTEM = "b"
elektra.modules.resolver_fm_hpu_b.constants.ELEKTRA_VARIANT_USER = "hpu"
elektra.modules.resolver_fm_hpu_b.constants.KDB_DB_DIR = ".dir"
elektra.modules.resolver_fm_hpu_b.constants.KDB_DB_HOME = "/home"
elektra.modules.resolver_fm_hpu_b.constants.KDB_DB_SPEC = "/home/jenkins/libelektra/build/config/spec"
elektra.modules.resolver_fm_hpu_b.constants.KDB_DB_SYSTEM = "/home/jenkins/libelektra/build/config/system"
elektra.modules.resolver_fm_hpu_b.constants.KDB_DB_USER = "cdbg-1/.config"
elektra.modules.resolver_fm_hpu_b.exports = ""
elektra.modules.resolver_fm_hpu_b.exports.checkfile = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.close = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.commit = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.error = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.filename = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.freeHandle = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.get = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.open = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.set = "(binary)"
elektra.modules.resolver_fm_hpu_b.infos = "All information you want to know is in keys below"
elektra.modules.resolver_fm_hpu_b.infos.author = "Markus Raab <[email protected]>"
elektra.modules.resolver_fm_hpu_b.infos.licence = "BSD"
elektra.modules.resolver_fm_hpu_b.infos.needs = ""
elektra.modules.resolver_fm_hpu_b.infos.placements = "rollback getresolver setresolver commit"
elektra.modules.resolver_fm_hpu_b.infos.provides = "resolver"
elektra.modules.resolver_fm_hpu_b.infos.status = "productive maintained specific unittest tested libc nodep configurable default"
elektra.modules.resolver_fm_hpu_b.infos.version = 1
elektra.version = "Below are version information of the Elektra Library you are currently using"
elektra.version.constants = ""
elektra.version.constants.KDB_VERSION = "0.9.2"
elektra.version.constants.KDB_VERSION_MAJOR = 0
elektra.version.constants.KDB_VERSION_MINOR = 9
elektra.version.constants.KDB_VERSION_PATCH = 2
elektra.version.constants.SO_VERSION = 4
elektra.version.infos = "All information you want to know"
elektra.version.infos.author = "Markus Raab <[email protected]>"
elektra.version.infos.description = "Information of your Elektra Installation"
elektra.version.infos.licence = "BSD"
elektra.version.infos.version = 1

(NOTA: removi as chaves .description da saída, porque elas contêm a string ``` e, portanto, quebram a formatação Markdown do Github)

Na verdade, a saída deve estar vazia, uma vez que todas as chaves são derivadas da instalação específica do Elektra e nunca devem ser importadas para qualquer KDB. Possivelmente, exportar as chaves version.constants pode fazer sentido, se kdb import ignorar corretamente (as outras version chaves também não devem ser exportadas).

~ Os problemas de Postcondition of backend was violated: drop key system:/elektra/modules/cache/infos/licence not belonging to "system:/elektra/modules/cache" with name "modules" but instead to "(null)" with name "(null)" because it is hidden by other mountpoint ocorrem apenas em # 3447 e apenas para o plugin cache . Portanto, ainda há um bug no # 3447. No entanto, corrigir esse kdb export problema também eliminaria o problema. ~

CORREÇÃO: Os problemas de pós-condição também ocorrem no contêiner do docker.

No contêiner de cima, corri (diretamente após as outras coisas):

ctest -R kdb_global_umount --output-on-failure

Depois disso, qualquer comando kdb que tenta acessar o KDB relata muitos postcondition avisos, por exemplo, kdb ls system .

Além disso, se tento executar kdb rm -r system , obtenho:

Interface: Read only plugin, 'kdbSet' not supported but the key system/elektra/version (value Below are version information of the Elektra Library you are currently using) tried to be removed

Essa kdb rm -r system falha é propositalmente. O que você esperava?

Devo admitir, porém, que a mensagem de erro é muito ruim (até gramatical e semanticamente: o usuário tentou algo, não a chave).

O que você esperava?

Para ser justo, sim kdb rm -r system não faz muito sentido em um sistema real. Em uma configuração de desenvolvimento, pode ser útil (mas excluir os arquivos manualmente também não é difícil).

Tenho que admitir, porém, que a mensagem de erro é muito ruim

Acho que é isso que mais me confunde. Se a mensagem dissesse algo como "removendo ... não permitido", eu teria entendido que fiz algo errado. Além disso, a AFAIK definimos Interface Errors como um erro no código e não algo causado pelo usuário.

Quanto ao plug-in version e plug-ins somente leitura em geral: Acho que deve haver uma maneira de ignorar esses erros de plug-ins somente leitura ao chamar kdb rm (talvez kdb rm -rf )
Em algum nível, "remover" chaves somente leitura faz sentido, pelo menos quando removemos tudo abaixo do ponto de montagem somente leitura de uma vez. kdb rm -r some/mountpoint deve remover todo o arquivo de configuração subjacente de some/mountpoint , ou seja, a pós-condição é que não há arquivo de configuração. Uma vez que plug-ins somente leitura (pelo menos aqueles que funcionam como version ) não têm arquivos de configuração, a pós-condição é satisfeita automaticamente.

Em uma configuração de desenvolvimento pode ser útil

Para desenvolvimento existe kdb reset .

Se a mensagem dissesse algo como "removendo ... não permitido"

Eu concordo plenamente! E quanto ao # 3498?

talvez kdb rm -rf

Acho -f confuso, já que você não pode forçá-lo, apenas ignorá-lo, então --without-elektra seria mais adequado?

deve remover todo o arquivo de configuração subjacente para

Sim, este é o caso e o resolvedor cuida disso.

a pós-condição é satisfeita automaticamente.

Naja, há também a pós-condição que após kdb rm key kdb get key retorna uma chave não encontrada. Esta pós-condição não seria cumprida.

Mudar a mensagem de erro deve ser suficiente

Existem bugs restantes descritos neste problema?

AFAIK este e o próximo comentário (ou seja, o problema original) ainda não foram resolvidos: https://github.com/ElektraInitiative/libelektra/issues/3299#issuecomment -695814469

Desculpe, parece que eu entendi mal esse problema no início. Deixe-me recapitular para ver se entendi corretamente agora.

Do ponto de vista do cache, queremos reutilizar os arquivos mmap tanto quanto possível. Assim, se alguém chamar kdbGet em "system/this" e o ponto de montagem for realmente "system" , persistiremos "system" completamente. Quando alguém chama kdbGet em "system/other" , o cache já está presente, o que acelera um pouco as coisas. Basicamente, criamos um arquivo de cache mmap por ponto de montagem, mas armazenamos TODAS as chaves abaixo do ponto de montagem.

Se entendi o problema corretamente agora, o que você quer dizer é que o armazenamento em cache de "system/elektra/modules" e similares são ambos:

1. errôneo e
2. irrelevante, já que buscar essas chaves é rápido de qualquer maneira.

EDITAR: Atualmente, obter o cache evita completamente o ksAppend e outras operações. Assim preservamos o OPMPHM e tudo. Se iniciarmos o ksAppend-ing "system/elektra/modules" para o resto do ponto de montagem do sistema, certamente perderemos algum desempenho. Talvez não seja relevante para o espaço de nomes do sistema, mas certamente prejudicaria o desempenho se tivermos casos extremos como esse em todos os lugares.

Nota: Eu marquei os comentários sobre kdb rm system como resolvidos, então eles estão ocultos pelo Github. Isso deve tornar a questão um pouco mais clara.

Se entendi o problema corretamente agora, o que você quer dizer é que o armazenamento em cache de "system/elektra/modules" e similares são ambos:

1. errôneo e
2. irrelevante, já que buscar essas chaves é rápido de qualquer maneira.

Apenas armazená-los em cache é errado, sim, mas ainda podemos armazená-los em cache, desde que haja alguma lógica para detectar que as chaves foram alteradas. Não posso comentar sobre a velocidade, mas usar o cache ainda pode ser mais rápido. Como você disse, ele evita ksAppend e também muitas chamadas para plug-ins.

O problema original é apenas sobre o comportamento de kdb export . Sua saída nunca deve conter nenhuma chave abaixo de system/elektra/modules ou system/elektra/version , uma vez que são específicas para a instalação do Elektra e não devem ser importadas para outro KDB.

Eu não investiguei de onde vêm essas chaves, então não tenho certeza se o plugin cache está realmente envolvido aqui. A melhor solução pode ser sempre ksCut essas partes em kdb export . Dessa forma, o problema não pode reaparecer se algo mudar.

Há também o problema "A pós-condição de back-end foi violada". Meu entendimento até agora é que esse problema é causado por kdb export produzindo chaves em system/elektra/modules , mas estou 100% certo:

Se você seguir as etapas em https://github.com/ElektraInitiative/libelektra/issues/3299#issuecomment -695814469 e, em seguida, execute

ctest -R kdb_global_umount --output-on-failure

bin/kdb ls system

(como eu disse no próximo comentário), você receberá muitos:

Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/licence not belonging to "system/elektra/modules/cache" with name "modules" but instead to "(null)" with name "(null)" because it is hidden by other mountpoint

Esta é realmente a única referência ao plugin cache . AFAICT isto é o que acontece aqui:

• O procedimento de "Backup e Restauração" do teste usa kdb export e kdb import .
• De alguma forma, isso resulta nas chaves de system/elektra/modules/cache sendo persistentemente gravadas no arquivo elektra.ecf .
• Quando então chamamos qualquer forma de kdbGet via, por exemplo, kdb ls system , temos o problema.
• Não tenho certeza de qual é exatamente esse problema, mas estou certo de que uma chave system/elektra/modules/... nunca deve ser gravada no disco.
• A única maneira de recuperar é _manualmente_ removendo as chaves system/elektra/modules/... de elektra.ecf .

Possivelmente, isso deve ser corrigido em kdb import não no cache.

Muito obrigado por relatar isso!

O cache definitivamente armazena essas (quaisquer) Chaves se elas estiverem presentes no KeySet retornado de kdbGet . Não há exceções para o cache. No entanto, como você disse, não faz sentido permitir essas chaves em kdb import . Vou ver se consigo reproduzir isso de sua descrição e corrigi-lo.

Se o problema ocorrer apenas ao usar kdb import , eu simplesmente descartaria essas chaves especiais na importação.

Concordo com @mpranj que o cache deve retornar tudo por completo.

Sua saída nunca deve conter nenhuma chave abaixo de system / elektra / modules ou system / elektra / version, pois eles são específicos para a instalação do Elektra e não devem ser importados para outro KDB.

Exportar não serve apenas para importar, mas também para exibir várias chaves / valores para um usuário. Não há nada de errado em kdb export system/elektra/version/constants simpleini para ver todas as informações da versão.

Não investiguei de onde vêm essas chaves, então não tenho certeza se o plug-in de cache está realmente envolvido aqui. A melhor solução pode ser apenas executar o ksCut nessas partes na exportação de kdb. Dessa forma, o problema não pode reaparecer se algo mudar.

Tal ksCut acontece quando você diz --without-elektra . O que poderíamos fazer é alterar o padrão: excluir elektra por padrão, exceto quando explicitamente importar / exportar / elektra ou dizer --with-elektra .

A pós-condição de back-end foi violada

Este parece ser um bug não relacionado. (Talvez o shellrecorder não esteja usando --without-elektra ). https://github.com/ElektraInitiative/libelektra/issues/3299#issuecomment -695814469, no entanto, parece que deveria ser. (Não consigo reproduzir, recebo Error response from daemon: pull access denied for elektra-fedora-32, repository does not exist or may require 'docker login': denied: requested access to the resource is denied. )

Eu não consigo reproduzir

Não publicamos esta imagem no hub do docker.

A pré-condição aqui é que ele construa a imagem docker de scripts/docker/fedora/32/Dockerfile e marque a construção com -t elektra-fedora-32:latest ao executar docker build .

Algo como:

cd scripts/docker/fedora/32/
docker build -t elektra-fedora-32:latest -f ./Dockerfile .

Obrigado, sim, posso reproduzir os problemas Postcondition of backend was violated agora no mestre (conforme descrito por @kodebach na imagem do docker e, em seguida, usando comandos de montagem globais):

 Sorry, 17 warnings were issued ;(
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/exports not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/exports/close not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/exports/get not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/exports/open not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/exports/set not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/author not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/description not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/licence not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/metadata not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/needs not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/placements not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/provides not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/recommends not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/status not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/version not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint

O problema não está claramente relacionado a kdb export , pois também ocorre, por exemplo, com kdb ls ou kdb cache clear .

Curiosamente, kdb cache clear não ajuda, mas ainda pode ser um problema de cache (como kdb ferramentas primeiro use KDB para obter sua configuração).

@mpranj você tem uma ideia?

O que poderíamos fazer é mudar o padrão: excluir elektra por padrão, exceto quando explicitamente importar / exportar / elektra ou dizer --with-elektra.

Sim, essa seria definitivamente uma solução melhor. Idealmente, também diferenciaríamos entre system/elektra/modules / system/elektra/version e o restante de system/elektra . A configuração do ponto de montagem e a configuração do plug-in global são muito mais úteis do que os módulos e as chaves de versão (que são geradas em tempo de execução).

O problema não está claramente relacionado a kdb export , pois também ocorre, por exemplo, com kdb ls ou kdb cache clear .

Como afirmei, o material "Pós-condição" é provavelmente um bug em kdb import .

Curiosamente, kdb cache clear não ajuda

Por que seria? Como eu disse, o problema é que system/elektra/modules chaves estão armazenadas em elektra.ecf . Se você seguiu minhas etapas acima (usou especificamente as mesmas cmake opções), poderá ver isso executando

cat config/system/elektra.ecf

dentro do diretório build .

Como afirmei, o material "Pós-condição" é provavelmente um bug na importação do kdb.

Como kdb import não faz muito mais do que criar um KeySet e chamar kdbSet , infelizmente, o problema está em kdbSet . O comportamento correto de armazenar qualquer coisa em system/elektra/modules deve ser um erro ou descarte e definitivamente não é persistente. Mas obviamente este não é o comportamento:

kdb set system/elektra/modules/NOTALLOWED
kdb ls system/elektra/modules
#> system/elektra/modules/NOTALLOWED
#> system/elektra/modules/cache
...

Portanto, quando um plugin NOTALLOWED é montado, temos o problema descrito aqui. Portanto, precisamos que kdbSet falhe em qualquer tentativa de gravar em system/elektra/modules .

Na verdade, precisamos definir a semântica de toda a hierarquia /elektra , o que provavelmente é uma tarefa maior ...

o problema é que as chaves do sistema / elektra / modules são armazenadas em elektra.ecf

Desculpe, não vi quando estava pulando entre os comentários tentando reproduzi-lo