Bug 178031 - digikam: missing BR: libtiff-devel, libjpeg-devel
digikam: missing BR: libtiff-devel, libjpeg-devel
Product: Fedora
Classification: Fedora
Component: digikam (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Marcin Garski
Fedora Extras Quality Assurance
Depends On: 170602
  Show dependency treegraph
Reported: 2006-01-17 10:21 EST by Rex Dieter
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: 0.8.0-16
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-01-23 08:15:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Rex Dieter 2006-01-17 10:21:38 EST
FYI, these are all (should be!) pulled in by kdelibs-devel already, so shouldn't
be included in digikam too:

BuildRequires:  libXt-devel libtiff-devel libidn-devel libacl-devel
BuildRequires:  libart_lgpl-devel gamin-devel
Comment 1 Marcin Garski 2006-01-17 11:50:50 EST
Thanks for info. Bug is fixed in 0.8.0-15 release.

I've added this BR 3 days (7 days) before they have been added to kdelibs-devel
and qt-devel (libXt-devel).
Comment 2 Rex Dieter 2006-01-17 16:11:01 EST
Oops, spoke too soon, looks like
BR: libtiff-devel
is still required.

Even though kdelibs-devel pulls it in, I'd recommend still adding
BR: libtiff-devel
since digikam does link (directly) against it
Comment 3 Marcin Garski 2006-01-17 17:11:55 EST
I don't so, package compiled cleanly.

Digikam also link directly against libjpeg, libfam and many others, so if I add
libtiff-devel I should also add the rest (which isn't necessary). AFAIR BR:
should include minimal packages set, so is now.
Comment 4 Rex Dieter 2006-01-18 09:16:13 EST
Just because the package compiles cleanly now, doesn't mean there isn't still a

kdelibs-devel has a *lot* of extraneous Req's, and I've filed bugs (see bug
#170602) to try to have that fixed.  This is why I'm suggesting you *not* rely
on those extraneous Req's for digikam to build properly.

IMO, apps that link directly to libfoo, should BR: libfoo-devel.  So, in
digikam's case, BR's should be added for: libtiff-devel, libjpeg-devel

The other stuff (including libfam as you mentioned) is just libtool baggage, and
should *not* be added.
Comment 5 Marcin Garski 2006-01-18 14:04:50 EST
I won't change this, unless there will be a clear guidelines. Look at bug
#168097, Aurelien Bompard wrote "* Duplicate BuildRequires: [...],
libtiff-devel, [...]".

This is a total inconsistency, if I want to include package in FE I should
remove libtiff-devel because it's a bug and then add it to BR because it's also
a bug.
Comment 6 Rex Dieter 2006-01-18 14:26:17 EST
I am sorry for the confusion and mixed signals... this is sometimes a complex

However, in this case, Aurelien is/was wrong.  Listing direct dependancies
(whether they seem duplicate or not) is *never* wrong.  Further, you're
depending on a current packaging bug in kdelibs-devel, which I hope to get fixed.
Comment 7 Michael Schwendt 2006-01-18 18:39:16 EST
Re: comment 5 - Okay, let's get this straight. We may need to bring
this to a higher level, so redundant BuildRequires are _not_ called
bugs without good reason. But for now, as a general rule of thumb:

Don't omit any _immediate_ build requirements just because something
else in the entire chain of build dependencies happens to depend on the
wanted build requirement already. It could be gone with an update.

If it is _your_ src.rpm which needs another package at build-time,
_you_ specify that package as an immediate BuildRequires in _your_
spec file.

Don't rely on an arbitrary package in the build dependency chain to
pull in any package _you_ need directly. Pull in the packages yourself.

[A bit repetitive, but hey, hope the message becomes clearer. ;) ]

Example 1: Your package uses both the Qt API and the KDE API.
You BuildRequires qt-devel and kdelibs-devel. You realise that
kdelibs-devel depends on qt-devel, but _nevertheless_ your package
depends on Qt. So you still BR both and don't optimise away qt-devel.

Example 2: You want GTK+ v2.x, you BuildRequires gtk2-devel. You don't
care that gtk2-devel needs glib2-devel, atk-devel, pango-devel. You
want gtk2-devel only. You're done. If gtk2-devel needs further packages
to be installed, but doesn't depend on them, it's broken. File a bug
report. In a new version of the software you package, the authors say
that Pango is needed. So you add BR pango-devel. This is already available
through gtk2-devel, but who cares? The software wants Pango, you now depend
on Pango, not just GTK+, so you BR Pango. Period.

Example 3: The software you package uses the KDE core API. You find it
in kdelibs-devel, so you BR it. The software also builds various image
format plugins, let's say TIFF, JPEG, PNG. You BuildRequires the
corresponding libtiff-devel libpng-devel libjpeg-devel and possible
regardless of whether kdelibs-devel may need them, too. Again, _you_
want them. You don't care whether kdelibs-devel needs them, too.
Comment 8 Marcin Garski 2006-01-20 07:08:48 EST
Michael your answer is great and clear. Now I get the point.
IMHO that answer with examples should be added to PackagingGuidelines
(BuildRequires section) on Fedora Project Wiki, and everyone who are involved in
FE should respect them (contributor, sponsors, etc) then things like my (add &
remove libtiff-devel) shoudn't happen again :)
Comment 9 Marcin Garski 2006-01-23 08:15:26 EST
I've added to BR:
qt-devel, kdelibs-devel, arts-devel, libtiff-devel, pkgconfig

Now this bug should be fixed, thanks for all your answers.

Note You need to log in before you can comment on or make changes to this bug.