New /bin/sh based script to manage ports

Panagiotis Astithas past at ebs.gr
Tue Feb 7 01:32:50 PST 2006


Doug Barton wrote:
> 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.

Mmm, I see. The last time I saw this it could have been gtk.

>> 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

This makes sense. So I guess the instructions in UPDATING are mainly for 
curing ports that use static linking.

> 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.

Thanks for the tip.

> 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.

I was referring to questions like, 'update port X? [n]' and 'delete 
foo.tgz? [n]'. I figured, since I asked for a '-rd' update, this was 
redundant. It is not very annoying, unless you have a few hundred ports 
to update. Although, given your advice above, I will be doing it less 
often. I should also confess that I'm contemplating a completely 
non-interactive invocation of portmaster from sysutils/bpm or similar, 
where such prompts would be prohibitive.

Thanks,

Panagiotis


More information about the freebsd-ports mailing list