| Summary: | emerging libexif-0.5.10 from libexif-0.5.9 breaks jpg applications | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Brian Nickel <kerrick> |
| Component: | [OLD] Library | Assignee: | Martin Holzer (RETIRED) <mholzer> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | foser, liquidx, lisa, mholzer |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Brian Nickel
2003-08-12 13:40:57 UTC
Moving from 0.5.9 to 0.5.10 also causes problems with opera 7.2-beta3. Opera 7.2-beta 3 has a depend on =libexif-0.5.9. Is libexif slottable? how about 0.5.12 ? although some of our apps use it, we never touched libexif. Please reassign. By the way, I'm pretty sure the reporter here isn't using official Gentoo provided eog ebuilds -those don't have exif support- invalidizing his report. But we might run into this in the future, so the exif maintainer should have a look at it and make sure the lib follows proper libtool versioning. Note to reporter : please, we don't support non-gentoo ebuilds. You shouldn't come here if you run into trouble with them, any trouble. If you want support, stay with the official tree and just that. This makes me want to trash this bug, valid in itsself or not. Martin : it seems 0.5.9 isnt properly .so versioned, but 0.5.10 is and so is 0.5.12 . So upgrading from apps linked vs. 0.5.9 won't work. Recompile the apps vs 0.5.10 and upgrade to 0.5.12 will work fine. In time the problem should resolve itsself. what happens if you run revdep-rebuild? lisa? Follow up on my comment in #3 : a working solution would be to introduce 0.5.12 and have it make an extra symlink 'libexif.so.8 -> libexif.so.9' in the ebuild. That should easy the upgrade path. In time the symlink could be removed (on newer versions). The only thing that could happen (not sure it does) is that if you recompile against a 0.5.10+ exif it links to the .8 shared object, but that could be easily tested and i don't think it happens. the symlink hack would probably be the best solution. but maybe someone should check with the libexif devs to see if there has been any major api change that would warrant a change in the major library verison number? Added note about upgrading from older version. The note that was added says if upgrading from 0.5.8 you'll need to run revdep-rebuild. I believe it should say 0.5.9 for two reasons. 1. I encountered this bug while upgrading gphoto2 which upgraded from libexif 0.5.9 to 0.5.12 and produced this bug. Running revdep-rebuild fixed it. 2. This bug 26498 originally refers to 0.5.9 - 0.5.10 upgrade - was the 0.5.8 a typo? If this was intentional then the note should say "from either 0.5.8 or 0.5.9 " |
