Summary: | Hard-wired dependency on Marble | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | Patrick O'Callaghan <pocallaghan> |
Component: | Geolocation-Marble | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED NOT A BUG | ||
Severity: | wishlist | CC: | bugzilla.kde, caulier.gilles, fedora, kevin.kofler, rdieter |
Priority: | NOR | ||
Version: | 0.10.0 | ||
Target Milestone: | --- | ||
Platform: | Fedora RPMs | ||
OS: | Unspecified | ||
Latest Commit: | Version Fixed In: | 7.5.0 | |
Sentry Crash Report: |
Description
Patrick O'Callaghan
2009-04-23 23:58:42 UTC
One possible way of doing this would be to allow Digikam to support plugins (via KService) which handle different EXIF tags. This would allow any new tags to have a view and old ones have different views easily. This is problem also for Windows version. You should remember that this is packagers problem - even if Marble will be only runtime dependency they will "force" relation... I'm totally agree with Mik. It's a packaging problem. Marble need data file (maps), else it crash at startup... We (digiKam team) cannot do anything. Other packaging problem is about marble-devel which never exist (for ex, here ith Mandriva). We need to install kdeedu-devel package... Gilles Caulier Is marble still needed when digiKam is compiled without MarbleWidget? If so it might be a digiKam problem, because then packagers simply can't disable marble support. I only find the option "With MarbleWidget" in cmake config... so I don't know if this includes geo-tagging as well. If disabling MarbleWidget also removes marble dependency, then it is a fedora problem. They could provide a simpler package in this case. Archlinux does so, too: http://bbs.archlinux.org/viewtopic.php?id=68393 Mayn users complain that digiKam has so many dependencies, some of them can't be removed (KDElibs related), some of them can (so this has to be by the packager). Andi Looking at the PKGBUILD file of digikam-slim, it seems to disable the widget, maybe this is really enough? http://aur.archlinux.org/packages/digikam-slim/digikam-slim/PKGBUILD Well I deinstall marble now and rebuild digiKam, so we have a clear answer :-) Andi If it is built without support for Marble, then no one can have the Marble support. This isn't really an I think it would probably be best if it could be made Argh. Control activated access keys and "O" is submit. Anyways, what I was going to say: If it is built without support for Marble, then no one can have the Marble support. This isn't really an option for distros that don't have users build from source for everything. I think it would be best if Digikam would use plugins via KService to handle EXIF tag visualization. This would allow the Marble dependency to be only needed when the then-optional marble plugin is installed. +1 for Ben solution, this could also apply to kdepim(libs) dependency IMHO this report is invalid. The Marble library is linked in, so it has to be a compile-time decision. And no, we have no intention of disabling this in Fedora. Disk space is cheap. Nowhere in my report did I mention disk space, which is indeed cheap. However bandwidth is not cheap for everyone, and some people even have download caps. Taking your position to its logical conclusion, why are rpm packages split into binary, source, devel and debuginfo, rather than bundling everything together in one lump? Because most people only want the binary? So what, disk space is cheap ... I agree with Kevin comment #9. Also, there is no plan to make digiKam with an optional support of Geolocation feature... Gilles Caulier |