[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Kind request: fix your packages




Michael Schwendt wrote:
-----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.

Add macros to the spec near the begining for the distros/version _you_support. Then include usage in the instruction on building your opackage. so they need only '--define RHL7.3=1' , '--define RHEL3=1',
or '--define MDK9=1'. That give you the same result of using redhat-release, package or file, and the ability to support more distributions at the same time.


Each of the above defines set orther such as _with_aspell_0.3, or _with_aspell_0.5. These can then be overridden but the user easily as well. So you could more easily build for an older distro with a newer version of library.

I think Mike Harris does a really good job of this for XFree86, and the kernel spec is getting there.

The spec file should not be doing RPM querries or checking files.
Perhaps I want to build a RHL7.3 RPM on my RHL9 box? If /etc/redhat-release is used, I get RHL9 versions regardless. If macros are used I can tell rpm easily to default to RHL7.3, use adifferent gcc, and alrternate libs as desired.


-Thomas




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]