Subject: pkg/21097: runtime dependencies should not be recursively registered
To: None <gnats-bugs@gnats.netbsd.org>
From: None <tv@pobox.com>
List: netbsd-bugs
Date: 04/11/2003 16:52:50
>Number:         21097
>Category:       pkg
>Synopsis:       runtime dependencies should not be recursively registered
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Fri Apr 11 13:59:03 PDT 2003
>Closed-Date:
>Last-Modified:
>Originator:     Todd Vierling
>Release:        NetBSD 1.6.1
>Organization:
	DUH.ORG:  Pointing out the obvious since 1994.
>Environment:
>Description:

At a time in hitory, pkgsrc was smart.  That is, it was smart enough only
to register the first level of dependencies in a package (installed or
.tgz form), allowing the dependencies to have their own (independent)
dependency lists.

These days, a package gathers all of its dependencies' dependencies --
recursively -- for package registration.  This is very bad, for a
trivially demonstrable example.

>How-To-Repeat:

Note that I'm not picking a specific real-world example here to avoid
bickering over package specifics, but I could point out the
perl5-base/perl5/p5-CGI dependency yo-yoing some time ago as one of the
several major inspirations here.

  pkg1 -> X11 GUI to image manipulation tools
  pkg2 -> command line image manipulation tools used by pkg1
  pkg3 -> image processing library used by pkg2

The dependencies are, of course:

  pkg1 => pkg2
  pkg2 => pkg3

When installed, however, the dependencies are:

  pkg1 => pkg2 AND pkg3
  pkg2 => pkg3

even though pkgsrc/category/pkg1 knows nothing about pkg3 and couldn't
care less about its presence.  That's fine and dandy, though, because
everything runs fine and the dependency tree is solid.

Now it's time to update pkg2, which is completely binary compatible with
its old version in use by pkg1.  So, in theory, the binary package built
earlier by "make package" whould work, allowing us to recompile only pkg2,
right?

But there's a snake in the grass.  In the new version of pkg2, the image
processing library formerly represented by pkg3 is now integrated, pkg3 is
no longer in pkgsrc, and pkg2 has a CONFLICTS on pkg3 to avoid clobbering.  
That means that the binary package for pkg1, which never cared about pkg3
at all, is no longer usable -- the recursively registered pkg3 dependency
hoses it.

Would someone please enlighten me as to why recursing for dependencies was
a good idea, again?  Perhaps it was useful in the days when dependencies
always pulled in explicit versions, but today, with Dewey depe3ndencies,
it's a real PITA.

>Fix:

Here's a trivial patch to bsd.pkg.mk that allows disabling of recursive
registration.  IMNSHO, the code block should be ripped out wholesale to
eliminate the recursion altogether.

Index: bsd.pkg.mk
===================================================================
RCS file: /cvsroot/pkgsrc/mk/bsd.pkg.mk,v
retrieving revision 1.1164
diff -u -r1.1164 bsd.pkg.mk
--- bsd.pkg.mk	2003/04/10 20:32:28	1.1164
+++ bsd.pkg.mk	2003/04/11 20:38:22
@@ -3471,6 +3471,7 @@
 # (i.e. when calling for pkg_create args, and for fake-pkg)
 # Will probably not work with PACKAGE_DEPENDS_WITH_PATTERNS=false ...
 PACKAGE_DEPENDS_QUICK?=false
+PACKAGE_DEPENDS_RECURSE?=true
 .if !target(run-depends-list)
 run-depends-list:
 .  for dep in ${DEPENDS}
@@ -3486,6 +3487,7 @@
 			${ECHO_MSG} "Warning: \"$$dir\" non-existent -- @pkgdep registration incomplete" >&2; \
 		fi;							\
 	fi;								\
+	if ${PACKAGE_DEPENDS_RECURSE}; then 				\
 	if ${PACKAGE_DEPENDS_QUICK}; then 				\
 		${PKG_INFO} -qf "$$pkg" | ${AWK} '/^@pkgdep/ {print $$2}'; \
 	else 								\
@@ -3494,6 +3496,7 @@
 		else 							\
 			${ECHO_MSG} "Warning: \"$$dir\" non-existent -- @pkgdep registration incomplete" >&2; \
 		fi;							\
+	fi;								\
 	fi
 .  endfor
 .endif # target(run-depends-list)
>Release-Note:
>Audit-Trail:
>Unformatted: