Kind request: fix your packages

[Sean Middleditch]

On Wed, 2003-10-01 at 17:46, Michael Schwendt wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Wed, 01 Oct 2003 15:34:32 -0400, Sean Middleditch wrote:
> 
> > No, you need to actually do the work of the configure script (perhaps
> > you should actually use the app's configure script) - detect the
> > individual bits in the system. Otherwise your package is broken.
> 
> What you describe is a maintenance nightmare. Assume an application
> wants aspell >= 0.50, but distribution B provides only aspell 0.30. A
> versioned build requirement on aspell >= 0.50 won't suffice, because
> the package won't build on B. But there is a configure switch to
> disable aspell support. So, what we can do is either examine aspell
> version somehow, e.g. with 
> 
>   $(rpm -q --qf "%{version}" aspell)
> 
> or check a file like redhat-release.

(pre-note: if I sound harsh, it's not personal - this whole problem
itself is just amazingly infuriating, and isn't a result of any one
person.  my apologies afore-hand for a semi-heated email.)

Which is broken.  You are working around the problem instead of fixing
it.  Redhat-release doesn't tell you anything about the version of
aspell installed.  I quite often have tons of RPMs installed on a stock
RH (or now Fedora) system; 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?

And no, installing new packages doesn't make me an "advanced user."  Or,
at least it shouldn't - I guess I have to be thanks to packages being
made using a broken packaging method.  Users should just be able to grab
any package online they want, and install it.  A friend points them to
MagicFishSoftware.com and the cool nifty Swordfish Spreadsheet app
there, they should just be able to click on the "Download Linux Package"
link, and watch it install.  Oh, it needs the new aspell?  Great, it's
grabbed automatically for them, and *boom*, they've got an upgraded
aspell, and redhat-release is useless in that regard.

Or, heck, the new Fedora policy states that security holes will often be
fixed by providing a whole new version, not just backporting a fix.  Is
fedora-release now supposed to also list all the legitimate security
patches it has so your can packages can have -fc1, -fc1-openssl4,
-fc1-db5, -fc1-openssl4-db5 variants and so on?

If the software can use aspell, but has a switch to disable it, the
software is badly designed, because it creates an unfavorable
situation.  If aspell has different ABIs for different versions, but
those versions can't be co-installed, then aspell is also broken.  You,
and other packagers, want to continue screwing over users with these
insane/broken development and packaging policies, versus just fixing the
problem once and being done with; libraries with changing ABIs need to
be co-installable, and apps shouldn't have wildly different feature sets
that can't be changed/detected at runtime.  If the app does depend on
libraries made by uncaring developers that can't keep a stable ABI, then
package the library with the app, and save the user the pain of dealing
with it; sure, it bloats the package size a bit, but that's the price to
pay for using poorly managed libraries.

If the app absolutely can't be packages without breaking all these rules
of sane design, then perhaps it shouldn't be packaged - if the only
people whom can install it easily are people who compile it, then it
seems a bit of a waste of time to package it anyhow; I guess its your
time to waste building 10 versions of a package that should only ever
need just 1.

If the app is compiled for an old aspell, but the user only has a newer,
incompatible aspell, then the user should just install the old aspell. 
Some apps use the newer one, some the old - this is the wonder of
versioned libraries, something we should be making use of, instead of
banishing users to DLL^w.so hell.

Fedora is about new technology, not continuing in the same nightmarish
unuserfriendly broken hack technology.

*please*, let's not do that to users, ok?  :)
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.