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).

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

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.

Just because the package compiles cleanly now, doesn't mean there isn't still a
problem.

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.

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.

I am sorry for the confusion and mixed signals... this is sometimes a complex
issue.  

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.

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.

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 :)

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.