Pergunta

Eu gostaria de perguntar sobre o raciocínio por trás do fato de que o plugin sbt-native-packager cria um link simbólico /etc/ -> /usr/share//conf (em vez de realmente colocar arquivos lá e de alguma forma especificar no aplicativo onde procurá-los)?

Em particular, como isso influencia o processo de atualização/desinstalação+instalação?As configurações são preservadas de alguma forma (por exemplo, para debian com configuração de arquitetura java_server)?

Foi útil?

Solução

Eu gostaria de perguntar sobre o raciocínio por trás do fato de que o plugin sbt-native-packager cria um link simbólico /etc/ -> /usr/share//conf

Mantendo tudo em um só lugar.Você tem o diretório do seu aplicativo que contém tudo e então basta vincular as pastas específicas do sistema operacional aos diretórios correspondentes na pasta do seu aplicativo.

As configurações são preservadas de alguma forma

Sim, de fato.Você pode experimentá-lo com um aplicativo de jogo simples.Adicione isso ao seu construir.sbt

mappings in Universal <+= (packageBin in Compile, baseDirectory ) map { (_, base) =>
     val conf = base / "conf" / "application.conf"
     conf -> "conf/application.conf"
} 

Isso mapeará seu aplicativo.conf no conf pasta.Quando você constrói um pacote debian com

debian:packageBin

você pode ver em target/-/DEBIAN/conffiles uma entrada

/usr/share/<app-name>/conf/application.conf

Um apt-get remova seu aplicativo não removerá este arquivo, apenas um purga

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top