Am 14.01.2014 14:03, schrieb Michael Biebl: > Am 14.01.2014 11:44, schrieb Martin Pitt: >> Simon Pepping [2014-01-14 11:33 +0100]: >>> A number of applications depend on libudev.so.0, e.g. Google Chrome. >>> These applications solve the problem by creating a link libudev.so.0 >>> -> /lib/x86_64-linux-gnu/libudev.so.1. Many users are affected by such >>> failures, and on the web there are many questions about the problem. >>> >>> It would be better if the package libudev1 installs such a link. >> >> No, that would be a dangerous hack. There is a reason why the soname >> got bumped, as libudev1 removed a few obsolete symbols. Surely they >> are not likely to be used, but if an application does, and it would >> link to libudev.so.1 thinking it was libudev.so.0 it would crash. > > Oh right. Shipping a symlink is certainly not the right way to address > that. Have a look at [1] to see what damage such a symlink can have. > >> For those third-party applications I suggest either bundling >> libudev.so.0 or providing a libudev0 package along with it.
Or tell upstream to dlopen libudev if they want one binary to work with both versions. > That would be an option. Or notifying upstream to build against libudev1 If the package (chrome in your case) was built for wheezy and you install it on sid/testing, you might install the libudev0 package from wheezy [1]. That package should be co-installable with libudev1. Btw, please file a upstream bug for Chrome Browser. It should *not* create such a symlink in postinst. [1] http://packages.debian.org/wheezy/libudev0 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
