Kind request: fix your packages

[Michael Schwendt]

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

You're asking for completely generic rpms where the user, who has
upgraded a component way beyond the version which was shipped with the
original distribution, does not need to supply optional rpmbuild
parameters (such as --define _with_aspell=1) for a src.rpm to build
_with_ support for that optional component.

And what do you do when the user has upgraded aspell to a newer
version that is incompatible? This is another unsupported case.

Or maybe you want also backwards compatibility? A src.rpm for a new
distribution release which examines the installed compiler and applies
patches when it finds an older compiler?

Another example, a bit closer to what you have in mind: Examining a
build platform for decision on whether to apply patches or not.
Fedora.us does that for a few packages with rpm -ql for openssl. It is
checked whether openssl supports pkgconfig or not and in turn a patch
is applied or not. Depending on how many things need to be checked,
this can quickly result in nothing else than bloat and wasted effort.
If a user has customized his installation a lot, there is no reason
why he should not need to customize src.rpms at least a bit as well.

Not even addressing the feasibility of some tests. E.g. checking
whether additional libraries must be available and linked. Do you want
spec files to become as large as the average configure script? Such
configure scripts are included. The build requirements in a spec file
only make sure that the dependencies are pulled in roughly. The
configure script performs more detailed checks on whether everything
works.

> It's
> a lie to say that a package is an "RH8.0 package," because that's where
> you built it, when it runs on RH9 and FC1.  Which is a very common case,
> I might note.

Who cares? Who does the testing? A package is built for and tested on
a set of platforms. Packages are built for specific distributions or a
somewhat compatible family of distribution releases. If a different
platform happens to meet the package's requirements, consider yourself
lucky.

> If you take the cheap way out, then you have a poorly packaged
> application.  You also completely defeat the entire purpose of using a
> package manager like RPM; you might as well just go to using Slackware
> .tgz files.

This I don't understand at all, I'm afraid. Slackware pkgs don't know
dependencies like RPM does. Part of creating a src.rpm is devoted to
making sure the build is working on the target distribution.

> If it *is* so hard to do the proper feature detection at RPM build-time,
> then perhaps some fixes to RPM are in order.  If any fixing is going to
> be done, let's fix the *real* problem, not fix the workaround to the
> problem.  ;-)

It is wasted effort to check build requirements beyond package names,
package versions or distribution version. If spec files contained
build platform detection code in addition to a tarball's configure
script, who would maintain all that?

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

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

iD8DBQE/e0sk0iMVcrivHFQRArjFAJ9u/kNskAyKCnGB0VfFakUiVOoRaACeMS2W
PX8XJc+m9oDkXzYunc8euoQ=
=ZVVz
-----END PGP SIGNATURE-----