Do we know the impact of disabling compression? I don't think it is really a big problem. You are right with this, I'm still a bit stuck in another mindset, where we usually know, that we have only one version of a package... If we later decide that compression is desired we can still go with a text file with references. Anyway, do you think that extending the reference scanner would be a good idea?
2017-12-14 23:59 GMT+01:00 Ricardo Wurmus <rek...@elephly.net>: > Hi Gábor, > > The manifest file would not be sufficient. Take the example of > “java-usb4java”. It provides a file “share/java/usb4java.jar”, which > contains this manifest: > > --8<---------------cut here---------------start------------->8--- > Manifest-Version: 1.0 > Created-By: 1.7.0_161 (Oracle Corporation) > > --8<---------------cut here---------------end--------------->8--- > > When you open the Loader.class file that is included in the archive you > will notice that it contains this string: > > /gnu/store/iwjqaqr98daqbgwswqi5fi4w891bqh7d-libusb4java-0-1.396d642a5/ > lib/libusb4java.so > > This reference is currently dropped because it cannot be detected in a > compressed archive. The reference is not contained in the manifest, and > at build time we could only guess which references should be added to > the manifest. > > Unless we extend the reference scanner to deal with compressed files I > think that disabling compression in jars is the best approach. > > I’ll push this to master. > > -- > Ricardo > > GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC > https://elephly.net > > >
