Bug 190476 - Hard-wired dependency on Marble
Summary: Hard-wired dependency on Marble
Status: RESOLVED NOT A BUG
Alias: None
Product: digikam
Classification: Applications
Component: Geolocation-Marble (show other bugs)
Version: 0.10.0
Platform: Fedora RPMs Unspecified
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-23 23:58 UTC by Patrick O'Callaghan
Modified: 2022-01-07 16:45 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: 7.5.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick O'Callaghan 2009-04-23 23:58:42 UTC
Version:            (using KDE 4.2.2)
Installed from:    Fedora RPMs

Installing or updating digikam via Fedora rpms requires downloading and installing kdeedu-marble, a 30MB package, even if the user has no interest in the package itself. It appears that digikam uses marble for geo-tagging, yet many users will never need or want this. The installation of marble should be optional, even if it means losing the geo-tagging ability of digikam.
Comment 1 Ben Boeckel 2009-04-24 02:15:51 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.
Comment 2 Mikolaj Machowski 2009-04-24 10:24:20 UTC
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...
Comment 3 caulier.gilles 2009-04-24 10:29:17 UTC
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
Comment 4 Andi Clemens 2009-04-24 14:09:08 UTC
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
Comment 5 Andi Clemens 2009-04-24 14:12:26 UTC
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
Comment 6 Ben Boeckel 2009-04-24 17:15:32 UTC
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
Comment 7 Ben Boeckel 2009-04-24 17:21:45 UTC
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.
Comment 8 Mikolaj Machowski 2009-04-24 19:06:08 UTC
+1 for Ben solution, this could also apply to kdepim(libs) dependency
Comment 9 Kevin Kofler 2009-04-26 05:31:01 UTC
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.
Comment 10 Patrick O'Callaghan 2009-04-26 17:29:12 UTC
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 ...
Comment 11 caulier.gilles 2013-12-02 23:22:59 UTC
I agree with Kevin comment #9. Also, there is no plan to make digiKam with an optional support of Geolocation feature...

Gilles Caulier