| Summary: | libexif-gtk-0.3.3 won't build after libexif upgrade | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Morten Cools <morten> |
| Component: | Current packages | Assignee: | Jeremy Huddleston (RETIRED) <eradicator> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | a, adam, askwar, blubb, charles, dpblnt, fox2mike, graphics+disabled, kenyon, skennedy |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Ebuild for libexif-0.6.11
Ebuild for libexif-gtk-0.3.5 Patch to fix creation of Makefile.in in /po Patch for changes after aclocal/autoconf/automake Updated ebuild for libexif-0.6.11 Updated ebuild for libexif-gtk-0.3.5 |
||
|
Description
Morten Cools
2005-03-12 07:34:52 UTC
*** Bug 84986 has been marked as a duplicate of this bug. *** *** Bug 84987 has been marked as a duplicate of this bug. *** It seems the syntax for the exif_entry_get_value was changed before or in libexif-0.6.10-r1. The source code for libexif-gtk-0.3.5 has a version check against libexif for which format to use, but the version must be greater than 0.6.12 before it uses the correct syntax. (It checks for the presence of a header file, and defines HAVE_EXIF_0_6_12 if it exists). libexif-0.6.11 actually contains this header file, but there are some problems with the makefiles in /po, which require patching. I have created two patches, one for the /po-makefile, and one to diff the updates done after running aclocal/autoconf/automake. Wether these patches are optimal or not, I don't know. They work for me, and that's all the testing I am able to do on them. So, to recap: I copied libexif-0.6.10-r1.ebuild to libexif-0.6.11.ebuild, edited it to use the two patches, and emerged it. Then, copied libexif-gtk-0.3.3.ebuild to libexif-gtk-0.3.5, edited that to remove the patching, and emerged it. Everything seems to be working now. I'll attach the patches and ebuilds, but someone a bit more versed in patch-making etc can probably improve them a lot. Created attachment 53281 [details]
Ebuild for libexif-0.6.11
Created attachment 53282 [details]
Ebuild for libexif-gtk-0.3.5
Created attachment 53283 [details, diff]
Patch to fix creation of Makefile.in in /po
Created attachment 53284 [details, diff]
Patch for changes after aclocal/autoconf/automake
I failed to notice this, but libexif-gtk-0.3.5 changes the library from libexif-gtk.so.4 to so.5, and libexif-0.6.11 changes it's library from libexif.so.10 to libexif.so.12, so a notice of a revdep-rebuild should be in the ebuilds. I will update the ebuilds I provided. Created attachment 53292 [details]
Updated ebuild for libexif-0.6.11
Created attachment 53293 [details]
Updated ebuild for libexif-gtk-0.3.5
this really should not be in the gnome herd... gfx care to take over ? Same problem with libexif-0.6.12. This is still present with libexif-0.6.12-r2 The revdep-rebuild for libexif rebuilds about 8 packages (on my system) which takes quite some time. this is present on libexif-gtk-0.3.3 as well these patches/ebuilds WFM, though i had to rename libexif-0.6.11-autoconf-update.patch to libexif-0.6.11-fix-makefiles.patch as that's the name it calls in the ebuild. Got libexif-0.6.12-r4 working with libexif-gtk-0.3.5 after I had the same error with libexif-gtk-0.3.3 Patches and a version bump work for me as well, could we get this committed? It's preventing the emerge of gtkam, which is a great little camera app (way lighter than gthumb). this seems mainly a libexif thing. Regarding the proposed changes to libexif-gtk : I consider preserve_old_libs a hackish solution, it does not sound like a good idea to leave packs linked to an old .so version, dual linking may occur. The right solution is to fix libexif to use a sensible .so versioning scheme and get upstream to follow it, it is a bug. There is no reason to remove the patch from libexif-gtk, it has still a function. that's nice, but could we get some form of fix, hackish or not, into portage so the package actually builds in the meantime? *** Bug 95506 has been marked as a duplicate of this bug. *** Is there any due date for a fix? it's in portage now, thanks. *** Bug 112105 has been marked as a duplicate of this bug. *** *** Bug 119508 has been marked as a duplicate of this bug. *** |
