autoconf
[Top][All Lists]
Advanced

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

Re: checking for Berkley db 4.2 --> 4.3 upgrade


From: Ralf Corsepius
Subject: Re: checking for Berkley db 4.2 --> 4.3 upgrade
Date: Wed, 20 Jul 2005 06:55:42 +0200

On Tue, 2005-07-19 at 20:07 +0200, Stepan Kasal wrote:
> Hi,
> 
> On Thu, Jul 14, 2005 at 12:19:26PM -0400, Sam Steingold wrote:
> > > * David Boreham <address@hidden> [2005-07-14 08:42:46 -0700]:
> > > Wouldn't it be easier to simply read the version number ?
> ... 
> > isn't the whole idea of autoconf to avoid relying on version numbers?
> 
> no, it isn't, thought it might sound so.
> 
> Yes, you hear "test for features, not for version numbers".
> The reasoning is like this:
> Say that you observe a bug in latest "Fumix 7.1", which needs a workaround.
> If you activate the workaround for Fumix >= 7.1, you might loose in several
> cases:
>  1) if "Fumix 7.2" will fix the bug
>  2) if you encounter a patched version of "Fumix 7.1" which no longer has the 
> bug
>  3) if "Fumiris 2.0" will have the same bug
> 
> So if we speak about a general feature, it's better to test for the feature
> then to collect version intervals.
> 
> But if you want to use a function from a particular project, it's more safe to
> use version numbers:
>  ad 1) Future versions will probably still have the funtion.
>  ad 2) Older versions don't have it.
>  ad 3) If another project provides the same functionality, your build scripts
>        wouldn't be able to use it.
I strongly disagree on this - All "version" checks are unreliable and
should remain the absolute last resort if all else fail.

Rationale: "version checks" can only work if all existing shipped
binaries of a package provide identical functionality, i.e. if a package
doesn't have optional features nor has patches applied.

This almost never is the case in any OpenSource project.


Example: KDE's gcc-4.0.0 blacklisting. 

KDE tripped a bug in gcc-4.0.0 which affects a lot of KDE stuff, so they
wanted to be clever and blacklisting gcc-4.0.0. They missed that almost
all vendor-supplied gccs are patched, so whatever version number a
particular gcc might return on a system, has no actual connection to
whether this gcc is affected by the bug KDE found worth blacklisting gcc
for or not.

Ralf






reply via email to

[Prev in Thread] Current Thread [Next in Thread]