Kind request: fix your packages

Göran Uddeborg goeran at uddeborg.se
Thu Oct 2 19:33:13 UTC 2003


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.





More information about the fedora-devel-list mailing list