2010/11/5 Marcus Meissner <meissner@suse.de>:
On Fri, Nov 05, 2010 at 10:59:07AM +0100, Richard Guenther wrote:
On Fri, 5 Nov 2010, Andreas Jaeger wrote:
On Friday 05 November 2010 08:44:19 Ludwig Nussel wrote:
Andreas Jaeger wrote:
On Thursday 04 November 2010 21:53:38 Andrew Jorgensen wrote:
On Thu, 2010-11-04 at 21:16 +0100, Dirk Müller wrote: > On Thursday 04 November 2010, Pavol Rusnak wrote: > > It seems only Arch and openSUSE have 8.0, all of the rest uses > > v6 or libjpeg-turbo. > > Thats correct, mainly due to LSB requirements, which we chose to > ignore.
I'm going to recommend that we stop ignoring LSB requirements. There are some very good reasons to comply with LSB and we fail when we don't. This pixbuf loader bug is just one example.
There are different ways to fullfill LSB. For LSB it suffices if we have libjpeg6 available so that applications build against it work. We can still use libjpeg8 as default jpeg library. I'm assuming that v6 and v8 have different sonames...
Both libraries may nevertheless end up in the same process if a binary is linked against libjpeg6 as well as another distro provided lib that links against libjpeg8. Result is a crash due to clashing symbol names. IOW the application no longer works even though it only links against LSB libraries.
Exactly.
so, the question in this case should not be LSB compliance but what to do with libjpeg. From the previous discussion, it looks like going back to libjpeg6 or libjpeg-turbo might solve a couple of problems our users get with third party software - so let's do it.
Adopting a symbol versioning scheme would also do the trick. The trick is of course to choose one that matches what other distros do or to convince upstream to provide one. It's really not _that_ hard.
libjpeg8 has at least started one.
Not sure how Debian does implement the versioning for libjpeg6, it seems to do it at least.
I have been looking better at this. The http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps thing that I linked before isn't about versioning symbols as I misunderstood. It's just a way to map package versions with new symbols, so an automatic script looks at a binary, sees it requires a symbol that was introduced in version 1.2 of libA and so makes the package depend on "libA >= 1.2". It's basically the same than symbol versioning, but external and without the pixbuf bugfixing capabilities. The cause Debian's libjpeg62 package uses symbol versioning is because of http://www.mail-archive.com/debian-release@lists.debian.org/msg35322.html. They were more prudent than us with the libjpeg8 transition and made upstream release a new version, 6b1, with symbol versioning. The only problem is that I don't know where to obtain that 6b1 version anymore (http://www.ijg.org/files/ only has version 8). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org