Kind request: fix your packages

[Michael Schwendt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 01 Oct 2003 22:24:48 -0400, Sean Middleditch wrote:

> >   $(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? 

Predictable builds.

On the contrary, you aim at build sources which just pick up what's
there, resulting in unpredictable, untested builds.

> Why not just make everything a "Distro-X.Y" package, and
> forget dependencies, since we know which software versions Distro-X.Y
> has?

You would still need a list of build requirements, so missing
dependencies can be installed in incomplete build environments. Not
everyone installs everything.

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

This seems to refer to prebuilt (binary) packages and is an entirely
different matter.

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

No, fedora-release won't cover that. But build dependencies will need
to deal with that. A security or bug-fix update, which is a new
version instead of a backported fix, can require dependencies to be
rebuilt and shipped as additional updates. Of course, all rebuilt
packages will need to see new testing.

> If the software can use aspell, but has a switch to disable it, the
> software is badly designed, because it creates an unfavorable
> situation.

Why? Assume aspell support is truely optional.

> If aspell has different ABIs for different versions, but
> those versions can't be co-installed, then aspell is also broken.

Depends on how early in the development stage of aspell we are.

> You,
> and other packagers,

Side-note: I don't consider myself a packager. ;)

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

Hardly anyone prevents co-installation like

  libfoo 0.10 => package name "libfoo10", root directory /usr/lib/libfoo10
  libfoo 0.20 => package name "libfoo20", root directory /usr/lib/libfoo20

when it is necessary and there are soname conflicts. It can be
necessary when some dependencies stick to libfoo 0.10 while others
require the newer libfoo 0.20.

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

It is clever to share components where components can be shared.

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

?? Automatic package dependencies enforce that.

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

Same here. If a binary package requires libfoo.so.2, the user just
needs a package which provides libfoo.so.2. It doesn't matter whether
the package is called foolib or libfoo or foo. It must contain/provide
libfoo.so.2 and neither libfoo.so.1 nor libfoo.so.3. What you seem to
refer to are broken explicit package dependencies where the packager
was overambitious and added lots of package requirements explicitly
instead of letting RPM determine dependencies automatically. That's
causing Linux newbies to fail.

- -- 
Michael, who doesn't reply to top posts and complete quotes anymore.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/fJVu0iMVcrivHFQRAtapAJ0ci2OYYX15LDLgAxcin/PsK6rziACfX4uJ
L84Qzce66QEwQ6nrp2/TPdM=
=+WQ7
-----END PGP SIGNATURE-----