Doug Barton wrote:
B Briggs wrote:
[snip]
Unfortunately my ports were up to date except for openoffice.org-2.0
which I had listed as HOLD_PKGS in pkgtools.conf. Anyway, I let it run
and it stopped because it wanted to install linux-sun-jdk14 (You get the
manual fetch message in IGNORE=), which I had only used as a bootstrap to
get the native jdk15 installed, then later removed the linux version and
its distfile.
Looked back at prior threads and it looks like someone mentioned this
about 3 weeks ago.
I seem to have missed this message, sorry about that.
Here:
http://lists.freebsd.org/pipermail/freebsd-ports/2006-August/034430.html
I was just wondering if there was any progress along these lines.
FWIW, I changed the script on line 435 from dep_port_list=`make
$MAKE_ARGS all-depends-list` to dep_port_list=`make $MAKE_ARGS
run-depends-list && make $MAKE_ARGS build-depends-list`
That's a very interesting idea, which I have now done some testing on (with
a slightly different version of the patch). An examination of the code in
bsd.port.mk indicates that not only should this work, it also has several
advantages. Not the least of which is that it should be faster, and it
should avoid building dependencies that the user doesn't actually need,
either because of the case you documented here, or because 'make config' in
a dependent port would eliminate the need for that port. Frankly, I wish
I'd thought of this. :)
I've been running this for at least 2-3 days now, No problems whatsoever.
[snip]
I've created a patch that has the dependency list change, plus the
experimental work I'm doing on trying to handle alternate dependencies via
CONFLICTS. It's at http://dougbarton.us/portmaster-conflicts-depends.patch.
I would appreciate it if folks could at least test the dependency list hunk
of that patch, and report back if they have any problems. As I said, it
_should_ work, but it's a non-trivial change and I don't want to screw
things up for anyone.
Doug
Like I said, running for a few days now, and no problems. The main
difference that I can see is what happens with +REQUIRED_BY with
portupgrade tools. For instance:
make deinstall && make install does not seem to update +REQUIRED_BY,
neither does make deinstall && portmaster /usr/ports/X/Y - there is no
+REQUIRED_BY after make deinstall. (This is probably because of make).
The only way to get REQUIRED_BY back is to run pkgdb -F, and I want to
remove portupgrade. So the question is, is REQUIRED_BY just a
portupgrade thing? If so, then I'd make a request that portmaster only
uses the IMMEDIATE requirements in that file, run depends list and build
depends list or maybe just run depends list. bitstream-vera is listed on
a bunch of my ports in REQUIRED_BY files, but it's only required in
xorg-fonts-ttfonts to run, and this comes from the x11/xorg metaport. On
the other hand, if +REQUIRED_BY is used for packages, then I can
understand the recursive dependency. Bottom line is that it's much more
meaningful to me to see the direct dependencies.
The -list targets have confused me for a few days. It looks like what
portupgrade uses in REQUIRED_BY is equivalent to the output in make
pretty-print-run-depends-list. In addition to these:
pretty-print-build-depends-list
package-depends-list
all-depends-list
run-depends-list
build-depends-list,
Seems to me that all-depends-list recurses as far as it can until all
possibilities are exhausted.
pretty-print-*-depends-list seem to come from INDEX-*, but I can't see
how far it recurses (at least 1 level, but probably no more than 2).
Looks like pretty-print-run-depends-list is what is shown in
freebsd.org/ports
run-depends-list and build-depends-list seem to be what is needed for
portmaster (so far, unless anyone finds any other problems).
I'd like to say again that this is a nicely written script; I'm just a
c/c++/perl programmer with little experience in /bin/sh, but I found it
particularly easy to read portmaster.sh.
--
Bo Briggs
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
