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 just > 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. -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
