Subject: Re: pine probs: structure has no member named `always_spell_check'
To: None <firstname.lastname@example.org>
From: Quentin Garnier <email@example.com>
Date: 12/16/2002 21:58:58
Le Mon, 16 Dec 2002 21:42:31 +0100
Julio Merino a écrit :
> On Mon, 16 Dec 2002 21:12:52 +0100
> Quentin Garnier <firstname.lastname@example.org> wrote:
> > No, the problem here is that the pkgsrc was only partly updated. Thus,
> > the buildlink2.mk included was outdated WRT the pine package.
> > This is kind of a flaw in the buildlink design, but I don't think
> > there's
> *ehem* (see below) :p
Sorry, it went out louder than meant.
> > any simple solution to that : bumping a buildlinked package would mean
> > updating all packages that depend on it, and not doing that is
> > precisely one of the reasons buildlink is used.
> Version dependancies can be specified, even in the buildlink
> infrastructure. You could use something like:
> BUILDLINK_DEPENDS.pico= pico>=X.Y.Z
> But I do not know why we are not doing this on packages where we really
> know which versions require. I think that the version specified inside
> the buildlink2.mk file should serve as a "fallback".
> Any comments?
In fact, maybe the buildlink2.mk files doesn't even have to indicate a
dependency, but more of an information, like "I provide package version
X.Y.Z, give or take". Then, it's up to the package that buildinks it to
decide if X.Y.Z is enough.
The difference is that it's then up to the maintainer of a package to tell
which version it needs of each buildlinked package. And if there's no
information about this in the Makefile, the buildlink system could
consider it doesn't care, to keep current behaviour when you update the
source of one package but not of another.
Quentin Garnier - email@example.com
"Feels like I'm fiddling while Rome is burning down.
Should I lay my fiddle down and take a rifle from the ground ?"
Leigh Nash/Sixpence None The Richer, Paralyzed, Divine Discontents, 2002.