On Wed, 2006-07-05 at 22:09 +0200, Enrico Scholz wrote:
* there are already complains about redundant dependencies when
| BuildRequires: A-devel B-devel
is used and an A-devel -> B-devel chain exists
Getting a bit off topic, but if they're *really* redundant, there's
nothing wrong with such complaints. However, in some cases, the
complaints are not much more than fragile and more or less misinformed
attempts to optimize/minimize things written specfiles.
When both A-devel and B-devel are directly and independently used,
there's nothing wrong with explicitly requiring both, no matter if a dep
chain exists between them or not. However, if a direct dependency on
B-devel is inflicted some way by A-devel and the thing to be built
wouldn't "naturally" need B-devel otherwise, it can be argued that an
explicit dependency on B-devel is subject to bitrot and would be better
left out if BR: A-devel is there and A-devel pulls in B-devel.
Why should redundant information like
| Requires: C >= EVR
Mileages vary whether the version is redundant or not. The worst thing
that can happen is that it becomes outdated and thus useless if the
packager doesn't bother to track it. But when kept up to date, it will
help in cases such as those from my previous mail.
* I do not say that versioned dependency shall be forbidden; they
do not make sense and I am against a rule like
| I have some php-pear packages which specifically indicate they need
| php >= 4.2.0 some that say they need php >= 4.3.0. If these versions
| are specified by the package, they should be indicated in the spec
| file (IMO).
I tend to agree with the original poster.