[ On Sunday, May 19, 2002 at 13:58:30 (+0000), Martin J. Laubach wrote: ]
> Subject: Re: Managing lots of installed packages, buildlink and versions
>
> |  On the other hand Frederick Bruckman recently proposed a much saner
> |  alternativve to mucking with BUILDLINK_DEPENDS.* settings under the
> |  subject "Introducing a better way of updating packages (long)".
> 
>   I am well aware of his efforts, but I'm afraid you missed the point.

No, I'm _afraid_ I did not miss the point. :-)

> This is a completely different issue -- his proposal deals with the
> situation "I want to update a package that lots of other packages
> depend upon, but don't want to touch all dependent packages (now)".
> 
>   However, the issue we are talking about here is "I want to update
> some leaf package (no other packages depend on it), but due to
> buildlink magic it forces me to upgrade all packages it depends on
> to the most recent version".

The effect is the same regardless of where you start.  Ultimately you
will need to upgrade a library that's in use by other packages,
regardless of whether this goal is forced upon you or it is one you've
chosen for yourself.  Fredrick's proposed trick will potentialy solve
this conflict in all cases (at least for shared libraries -- changes in
command-line APIs will not be covered).

>   So while I can understand that if I touch, for example, libpng,
> everything needs to be rebuild, it's absolutely ridiculous to have
> to rebuild half of your packages because you upgrade, let's say,
> gnucash.

You might think so, but you'd be wrong!  :-)

If you want to do these sorts of things then you don't want to be using
pkgsrc.  You probably also don't want to be using third-party shared
libraries, though how you mange build-time and run-time dependencies
between multiple versions of such libraries outside of pkgsrc is your
problem....  :-)

>   After the original post here I thought up some mechanism how
> not to get this "update ripple effect" -- then I checked bsd.buildlink.mk
> only to find that _exactly_ what I had in mind is already implemented.
> It's just not used anywhere. Perhaps jlam as the author has some
> insight?

I believe the mechanism you're looking at is there for the opposite
reason you wish for it....  Certainly I've used it for the opposite
reason, and though I can't find an example I believe I've seen it
"officially" used in the same way I used it.

I.e. I believe it's there to force a dependency on a newer version than
the one allowed for by default, not to allow an older one.

> I feel that packages should state exactly which version of other
> packages they depend on -- and not rely on buildlink's mechanism
> of requiring whatever happens to currently be in pkgsrc.

I think the point is that what's in pkgsrc is expected to be
consistent.  The relational version dependency operators are there
simply to ease the maintenance nightmare, not for the convenience of
users.  Users not expected to follow the bleeding edge.

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>