>>>>> Steinar Bang <[email protected]>: >>>>> Jean-Baptiste Onofré <[email protected]>: >> Hi >> Do you have the resources in etc folder same as karaf vanilla ? The >> bnd version policy could cause such issues.
> Aaah... I am leaving some of the etc files from the previous version > during APT package upgrade (trying to keep user modifications, such as > e.g. added maven repos). > But maybe the default should be overwrite by maintainer's version for > all of them...? It is only added maven repos I want to keep out of alle > the provided etc files, as far as I can remember...? > I'll look into it! Thanks, JB! I figured out what the problem was. Summary here in case anyone should be interested. The problem was not that some files in /etc/karaf was left from the karaf 4.4.7 version. The problem was that the apache karaf debian package tries to fulfill its java jar runtime dependencies from debian packages, when available (with the hope of making it an official debian package once all of the runtime dependencies are fulfilled this way). And in the debian package libasm-java 9.8-1 the Bundle-version of the MANIFEST.MF of the jar file is broken: Bundle-version: 9.8-SNAPSHOT I have reported a bug on the libasm-java debian package https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1118387 For now the workaround will be to bundle the asm dependencies in the karaf debian package instead of having it provided from a debian dependency. For the record: the karaf debian package's handling of the etc directory during upgrades is correct as far as I can tell. Only the expected changes are found when diffing the debian package's etc directory with the etc directory of the official karaf binary tarballs for versions 4.4.7 and 4.4.8. For reference, unofficial karaf debian package https://github.com/steinarb/karaf-debian https://steinar.bang.priv.no/2018/01/23/packaging-karaf-with-native-debian-packaging-tools/
