Kind request: fix your packages

[Michael Schwendt]

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

On Thu, 02 Oct 2003 21:49:23 -0400, Sean Middleditch wrote:

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

Not necessary, because errata packages are backported fixes, not
feature upgrades.

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

Doesn't matter. It's the packager's (distributor's) responsibility to
provide a working set of dependencies. Those people, who send newbies
to rpmseek.com where the newbies chooses a prebuilt package for an
arbitrary distribution and fails to locate missing dependencies, are
nuts and are not helpful. It is much more helpful to point newbies to
repositories and tools like Synaptic.

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

That contradicts itself. Why would you leave around the old library
version if there is security hole in it? No need to keep the old one
and co-install the new one. The security hole must be fixed, no matter
how. Whether fixes are backported or applied as version upgrades, is a
matter of feasibility.

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

You're exaggerating. Smiley noted.

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

Depends on whether this "aspell support" is a completely separate 
plug-in or whether it is tied into the application. In either case, it
likely comes together with the source code for the application and is
built from within the same src.rpm. If the target platform doesn't
suffice, you can either disable optional features or not build the app
at all.

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

See above. You can only build that feature if build requirements are
met.

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

This doesn't change a thing. The case we're discussing is a new app
which uses the new API and doesn't build with the old API. It requires
the new app to be backwards compatible, too, i.e. to use the old
deprecated API. And at some point in time, the API user needs to
switch to the current interface, because the old API is dropped.

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

Tell that the typical rpm-dependency-hell troll. ;o)

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

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

iD8DBQE/fXyl0iMVcrivHFQRAkpgAJ9c4RcluvA0ig6LrlXqWmsokoMo8wCdHQd3
9d8XAAJtG9QdugqdUyFQBEw=
=fmQY
-----END PGP SIGNATURE-----