mk.conf. Problem is that it can use ccache/distcc if they are already
installed.
Sure, it could, but then it depends on them, and if both are dirty there
is no clear rebuild order. I think the the real problem is that there
is a circular dependency. If ccache/distcc depend on checkperms, then
checkperms should just not use those. Putting those lines in mk.conf
has the same effect anyway, but it doesn't fix the problem in pkgsrc,
just for me.
Maybe there isn't truly a circular dependency, but it seems that having
ccache in PKGSRC_COMPILER causes packages to have a build dependency on
ccache.
I think it's better for checkperms to not use ccache than it is for
ccache to skip permission checking. I don't see any other way out of
this if we accept that it's reasonable to tsort packages by dependecies
to decide how to rebuild.
I tried this:
Index: sysutils/checkperms/Makefile
===================================================================
RCS file: /cvsroot/pkgsrc/sysutils/checkperms/Makefile,v
retrieving revision 1.21
diff -u -p -r1.21 Makefile
--- sysutils/checkperms/Makefile 5 Dec 2009 10:23:34 -0000 1.21
+++ sysutils/checkperms/Makefile 14 Dec 2009 20:57:30 -0000
@@ -17,8 +17,10 @@ USE_BSD_MAKEFILE= yes
.include "../../mk/bsd.prefs.mk"
-# Avoid the "hen and egg problem"
+# Avoid self-referential and circular dependencies.
CHECK_PERMS= no
+IGNORE_CCACHE= yes
+IGNORE_DISTCC= yes
.if ${OPSYS} == "Linux"
MAKE_ENV+= NOGCCERROR=yes # see PR 35930
and after rebuilding checkperms once I had no cycles.
In this case checkperms has a tiny/fast build (1 compile, 1 link, 1 man
page), and I see no loss in having ccache and distcc not used (except
that nroff can't overlap the cc). Timing it shows that it is in the
noise - the serial build takes 1.5s on my not-very-fast box.
Another alternative is not to record ccache in "pkg_info -N", but it
seems it belongs.
I think pkg_rolling-replace's use of pkg_info -N is sound; if there is
an update to bison (bugfix especially) then packages using bison as a
build tool should get rebuilt. ccache is no different --- what if there
were a bug where it had the wrong output sometimes?
Attachment:
pgploFWFfghkt.pgp
Description: PGP signature