Kind request: fix your packages

Fri Oct 3 01:49:23 UTC 2003

On Thu, 2003-10-02 at 17:15, Michael Schwendt wrote:
> -----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.

Right.  But then you still can't detect errata packages and such when
building based only on /etc/release.

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

This then might be a source of our disagreement - I couldn't care less
abotu building packages, I only care about the actual users installing
them.  ;-)

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

Which is silly.  If a library/component is upgraded, it must either be
binary compatible (and thus not need rebuilt applications) or be
co-installable (in which case a backported fix for the old library would
be mandatory for a secure OS, but that's life.)

If you really want to have to rebuild the system everytime the user
coughs, perhaps you should be using Gentoo instead of Fedora... ;-)

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

Because it's completely insane to have to reinstall a whole different
version of the app to 'enable' a feature.  It's a lot less to do with
technically possible or code correct, and a lot more to do with just it
being a completely stupid way to design anything.  If it's optional,
make it a plugin or add-on, not something that conditionally built into
or outof the app.

It's like the difference between a wholly monolithic kernel or a kernel
with modules.  *yes*, there are cases the monolithic kernel is a better
choice (embedded systems, say) but those aren't end-user systems like
Fedora - they're built once and don't change.  Apps aren't any different
- if the app takes a monolithic approach, its design is broken.

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

This is true.  But then, as a library author, if you know you have tons
of apps depending on your ABI, it's rather good form to go thru the
extra effort to keep it stable.  You can add newer API's without
removing old, and flush the deprecated stuff out every several releases,
and move the soversion up while you're at it.  You can have a pre-1.0
app with a soversion of 23.4.6; the soversion has *nothing* to do with
release version of stability, only with interface version.

> 
> > You,
> > and other packagers,
> 
> Side-note: I don't consider myself a packager. ;)

Heheh, righty.  On the same hand, I don't really consider myself a
normal user, so we're evenly mismatched in this debate.  ^,^

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

Right... which is the solution to your "version of package depends on OS
release" argument.  If we both recognize the solution, what are we
debating?  ;-)

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

Where they *can*, yes.  When they can't be shared, because sharing
destabilizes the system, then its clever not to break things by
sharing.  ;-)

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

Right.

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

Right, I was going off a bit on a tangent from the original discussion. 
Sorry.  ^^;  (Once I start, I never realize when I need to stop again.)

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