New /bin/sh based script to manage ports

[Doug Barton]

Panagiotis Astithas wrote:
> On Fri, Feb 03, 2006 at 12:44:56AM -0800, Doug Barton wrote:

>> This depends on which direction you're approaching the problem from. When
>> building a port, the check for whether the dependencies of the port are up
>> to date uses the list from 'make all-depends-list', which will include build
>> dependencies. However, once a port has been built and installed
>> successfully, the list of ports which have a dependency on the updated port
>> is cross checked between the +REQUIRED_BY in the package directory and the
>> +CONTENTS files of the other installed ports. In this way we can be sure
>> that all appropriate dependencies are recorded, and updated. Since
>> BUILD_DEPENDS are not registered in the +CONTENTS or +REQUIRED_BY files,
>> they don't show up at that stage, and portmaster doesn't update information
>> about them (because that information doesn't exist).
> 
> And I've noticed that portmaster warns when there is a mismatch between 
> the dependencies in +CONTENTS and +REQUIRED_BY, where the latter are usually
> more than the former. However the default suggestion from portmaster is
> to use the +CONTENTS dependencies. Why is there a difference in the first
> place (port bugs I presume) and would the other approach be more correct
> (in that it would fix the unrecorded dependencies)?

Well, not having dependencies recorded in the +CONTENTS files, but having
them in +REQUIRED_BY would be fairly pathological. When the port or package
is built, it records its own dependencies in +CONTENTS, so that should
always be accurate, for sufficiently careful definitions of "always" and
"accurate." I'm not sure how you'd get a line for a port in +REQUIRED_BY in
a way that didn't let you get it back out again. That's why the default when
there is a mismatch is actually to use the +REQUIRED_BY set.

One common case where there will be a mismatch is a case like gtk-1 and
gtk-2. grep'ing for "gtk-" pkgdeps will get you both, so there is a
mismatch. However in a case like that the differences should be obvious.

> On another note, I tried yesterday a 'portmaster -rdf expat', which is a
> mega task on my system, so I would expect to get preferably zero questions
> asked (since we are talking about 200 ports here). This is what the relevant
> portupgrade invocation did (modulo the various OPTIONS screens), although
> 20 hours later it is still not finished. Could portmaster be persuaded to
> 'do whatever needs to be done, but you are on your own until you do it'?

Boy, you're just full of fun. :) First a meta-comment, I didn't rush to add
the -r option because in my experience, it's hardly ever necessary to
rebuild ports that depend on a port that you're going to be updating. One of
the few where I've found this necessary is gnutls, and then only for some of
the ports that depend on it. At least 95% of the time, I just update a port,
and the ports that depend on it still work. This is one of the joys of
shared libraries. :)  If you need to use the -r option, I would not
recommend adding the -f flag, as that would rebuild all of the dependencies
of the ports that depend on the -r port, which probably isn't necessary at
all. I wrote the -r option code to always rebuild the ports that depend on
the port you specify with -r, so the -f flag isn't needed to accomplish that.

Now to the substance of your question. I added the -[dD] options to help
with exactly the problem you describe. BTW, another way to speed the build
in this type of situation is to add the -C option. All that said, I'm not
exactly sure what you're asking for. If you're saying that you want an
option to suppress questions about updating dependency listings, I suppose
that could be added easily enough, but I would be very hesitant about that.
OTOH, I suppose we've not hesitated to put bullets in the foot-shooting gun
before, why stop now. :)  If you can clarify what you're looking for here,
I'll look at adding it.

Doug


-- 

    This .signature sanitized for your protection