[ On Friday, November 23, 2001 at 16:45:04 (-0800), Johnny Lam wrote: ]
> Subject: Re: buildlink.mk should maybe be installed with libraries?
>
> On Fri, Nov 23, 2001 at 02:03:33PM -0500, Greg A. Woods wrote:
> > [ On Friday, November 23, 2001 at 16:13:52 (+0100), Olaf Seibert wrote: ]
> > > Subject: buildlink.mk should maybe be installed with libraries?
> > >
> > > I see a potential for version skew with the current buildlink.mk system.
> > > 
> > > If you build a program P which depends on installed library L, then
> > > L/buildlink.mk is used.
> > > 
> > > But this version of L/buildlink.mk is the version for the most recent
> > > version in pkgsrc. Program P may not require the most recent version but
> > > may be happy with an older version that was installed earlier.
> 
> This is not true.  The buildlink.mk file may easily specify files from old
> versions of a package in BUILDLINK_FILES.<pkg>.  See gtk/buildlink.mk.

That's not the problem.  You're ignoring what happens when someone
follows pkgsrc-current (something far more common, in my estimation at
least, than people following netbsd-current itself).

> This is also why the dependency pattern in a buildlink.mk isn't set to the
> most recent package.

That's irrelevant.  I understand "most recent version" in the above to
mean "most recent version required by L/buildlink.mk", just as the
preceding sentence seems to try to show.  That's certainly where it's
tripped me up in any case.

A prefect example of a G.D. library with far too many interdependencies
in pkgsrc is the most aptly named graphics/gd.  In revision 1.4 of it's
buildlink.mk file the setting is:  BUILDLINK_DEPENDS.gd?= gd>=1.8.3
However if this is changed at any time then every package that directly
or indirectly uses libgd.so will have to be deleted and re-built after
the new graphics/gd has been built and installed before any other
previously uninstalled package that directly or indirectly uses libgd.so
can be built and installed, regardless of whether or not it really needs
the newer version.  In the case of graphics/gd the ripple effect with
further dependencies can be far and wide.  This is unecessarily
disruptive.  Users of pkgsrc-current should not be required to
'pkg_delete *' every time they update, especially when there's no real
hard reason to do so.

> > This isn't just a potential problem -- it's very real.  I've tripped
> > over it several times already myself!
> 
> Use send-pr to report these problems so that we may become aware of them
> and fix them.  I certainly haven't heard these problems.

If I have time I will -- but in this case the logic should be easy
enough to follow without a concrete example.  It's a design issue, not a
per-package instance bug, after all.

> > > In this case, the L/buildlink.mk does not belong to the installed
> > > version of L. To make sure that this can never be a problem, we must
> > > install L/buildlink.mk with L, so that when linking with L the
> > > buildlink.mk from that time is used.
> > 
> > Yes, I believe this is the correct solution, but with one possible
> > caveat:  I think The overloading of (BUILD_)DEPENDS with a default
> > BUILDLINK_DEPENDS.foo in the buillink.mk files needs to be removed.
> 
> No.  You may simply list the files from previous versions in the
> buildlink.mk.

No, you've missed the problem entirely I think....

The buildlink.mk files really _must_ be installed with the package that
supplies them, and other packages really _must_ use the installed
buildlink.mk file, if the (BUILD_)DEPENDS.foo settings are to remain in
those files.  The ">" relation really isn't appropriate in there either.

Even without the (BUILD_)DEPENDS.foo settings I believe it's still
better to install that buildlink.mk files as part of the product.  They
are after all used as part of the product, not as part of pkgsrc per se
(and especially not as part of the source package they belong to).  This
should simplify their maintenance tremendously too since now they are
specific to a given package version and no backwards compatabilty need
be maintained.  Never make something more complicated than it needs to
be!

The final clincher is that installing the buildlink.mk files as part of
the product would be one of the necessary pre-requisites to making it
possible to build part of pkgsrc, or even just one pkgsrc module, in
isolation (i.e. without having to have all of pkgsrc unpacked and
available in the same hierarchy).  This is something I've desired right
from the very beginning, and except for buillink.mk files, the rest of
pkgsrc has slowly been getting more capable of accomodating such a
scheme.

-- 
							Greg A. Woods

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