Sean Middleditch writes:
Redhat-release doesn't tell you anything about the version of
aspell installed. ...
if I happen to upgrade aspell on my own, and
your broken package is looking for my OS release instead of the actual
aspell package... what then again is the point of actually having
dependencies? Why not just make everything a "Distro-X.Y" package, and
forget dependencies, since we know which software versions Distro-X.Y
has?
I agree that relying on redhat-release for anything seems rather
dangerous. Not much would break if I removed the package altogether;
a little piece in rc.sysinit would give an error message, that's all.
Dependencies should accurately reflect what actually is needed, not
the bundling of versions in a particular release.
If the software can use aspell, but has a switch to disable it, the
software is badly designed, because it creates an unfavorable
situation.
I want to disagree a bit there. There could be good reasons to make
it possible to compile with and without a feature to support different
environments. The software maybe uses aspell only for some marginal
feature, and has a lot of uses without it.
In that case, it could make sense to have two different branches of
packages, one with and one without aspell dependency. Then the
package name should reflect the real difference, aspell or no aspell.
If it does, I know that is the point, and I can make a decision if I
want to upgrade aspell to a version from a more recent distribution,
consider what other dependencies that would affect, or if I want to go
for the version with a somewhat reduced functionality.
If the package branches instead point at two versions of RH/FC which
just happen to be before and after apsell was upgraded, I won't know
this. I won't know what the difference in functionality is, and I
won't have the information for a logical decision.