Kind request: fix your packages

[Sean Middleditch]

On Thu, 2003-10-02 at 15:33, Göran Uddeborg wrote:
> Sean Middleditch writes:

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

If it's a user-oriented feature, then it needs to be run-time
configured, not compile-time configured.  Users don't recompile apps,
just admins and developers.  (And those nuts using Gentoo ;-)

In the event of portability, i.e., the package is intended to work on
platforms that can't use aspell... well, that's not an issue for RPM
packages for Linux.

If the app can use aspell, and a user would expect that feature, or a
user could feasibly want that feature, then it needs to be enabled, and
the proper dependency made.  If aspell can't have multiple incompatible
versions simultaneously installed, package aspell with the app, or go
help the the upstream authors learn how to develop software properly. 
(note: i'm not saying aspell is badly developed, as I don't know if it
actually suffers from this problem; this discussion is hypothetical from
my point of view.)

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

This is still user hell.  A user should never ever have to deal with
this kind of non-sense.  If a feature is optional, it needs to be
run-time optional.  Otherwise, we end up with a piece of software either
having 20 different versions of the package for every set of possible
options, or broken hacks like distro-release dependent packages.  In
situations like this, plugins are the way to go, or package add-ons, not
two conflicting packages that are the exact same thing save one little
piece.

Yes, there are probably broken poorly developed libraries and broken
poorly developed apps that depend on those, and yes, there are people
who probably want those packaged.  I dare hope those are the exception
and not the rule; otherwise, we're all pretty much screwed so far as
usability goes.  ~,^

> 
> 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.
> 
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.