On Fri, 15 Oct 2004, Alistair Crooks wrote:

> On Fri, Oct 15, 2004 at 06:13:48PM -0400, Nathan J. Williams wrote:

> > pkgviews seems like a decent mechanism for having libfoo1.2 and
> > libfoo1.3, but much of the complaint I see in this thread is packages
> > demanding libfoo1.3 when they don't need it. In that respect, pkgview
> > will make things nicer, but only by papering over the underlying
> > problem.

I think the problem is that BUILDLINK_DEPENDS and BUILDLINK_RECOMMENDED
aren't being used correctly. I think the complaint is that dependencies
required are bumped without any real reason.

Even if there is a minor new feature (and library names don't change) --
BUILDLINK_DEPENDS doesn't need to be bumped system-wide. For example, if
only one or two other packages needs the new functionality, they can
temporarily list the BUILDLINK_DEPENDS.whatever dependency in their own
Makefiles.

For security issues, BUILDLINK_RECOMMENDED should always be bumped. I
don't know what else it should be increased for. But then again, package
maintainers can't easily test their NEW packages depending all up-to-date
packages as well as depending on the old versions too. It would be nice to
have a test machine available for pkgsrc developers that always had the
"old" dependencies installed (or packaged for quick reinstalls).

I believe that BUILDLINK_DEPENDS should only be increased if the SONAME
changes. So in the recent libtool improvements, instead of bumping
BUILDLINK_RECOMMENDED really all the BUILDLINK_DEPENDS should have been
increased (and BUILDLINK_RECOMMENDED removed because would be redundant).

I had been using the IGNORE_RECOMMENDED=yes since it was fixed in August
and finally yesterday, I realized pkgsrc for me was very broken under
NetBSD 1.6.x. (I gave up with IGNORE_RECOMMENDED=yes under Linux last
week.) So now I am using default IGNORE_RECOMMENDED=no. I believe
IGNORE_RECOMMENDED had great value in the end of August and during
September but because BUILDLINK_DEPENDS were properly bumped the
"RECOMMENDED" system became worthless!

I had suggested before that IGNORE_RECOMMENDED should default to "yes".
Then everyone by default would use the old (but proven) dependencies. Then
if RECOMMENDED was always disabled, then we could set
BUILDLINK_RECOMMENDED to the latest and greatest and those who choose to
use the RECOMMENDED system would get what they deserve :)

Then we'd have three ways to use pkgsrc (not counting pkgviews): stable
collection, current pkgsrc using BUILDLINK_DEPENDS (this would be the
default), and current pkgsrc using the RECOMMENDED.

I suggest that IGNORE_RECOMMENDED be renamed "USE_RECOMMENDED" and the
usaged reversed?

What do you all think about that?

Anyone else use IGNORE_RECOMMENDED (as it is) successfully over several
weeks? Anyone using it since it worked (mid August)?

Please let me know what you all think BUILDLINK_DEPENDS versus
BUILDLINK_RECOMMENDED should be?

> If you're talking about the open-ended dependency problem in pkgsrc, I
> thought we'd fixed that for binary packages when we added the @blddep
> stuff to pkg_add, but I see that others are less enamoured with that

I don't see @blddep being used though.

> We've started to record the shared lib "PROVIDES" and "REQUIRES" now
> in binary packages, so maybe we can look to use that, and trust to
> everyone being good citizens when changing ABIs and major numbers.

That would be great!

My main concern with pkgviews is that over time, I may end of numerous
multiple copies of same software. (My pkgviews experience was only using
it for about two months.) Is there any mechanism to automatically
look at all packages to see if any of the "views" can be removed?

By the way, I think a lot of the recent complaints had to do with two
things happening near each other: large buildlink/wrapper changes and then
libtool improvements (that had to be adjusted a few times).

(One of the problems that hit me was the libtool-base had to be updated,
but pkgsrc never forced me to update it so many packages failed for me. Or
they installed causing others to fail.)

 Jeremy C. Reed

 	  	 	 technical support & remote administration
	  	 	 http://www.pugetsoundtechnology.com/