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