[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
Re: checking for Berkley db 4.2 --> 4.3 upgrade, Paul Eggert, 2005/07/14
Re: checking for Berkley db 4.2 --> 4.3 upgrade, Mike Castle, 2005/07/27