ports rebuilt w/o good reason

[Boris Samorodov]

Ion-Mihai Tetcu <itetcu at freebsd.org> writes:

> In other words, if A -> B -> C -> D ( where '->' means depends),
> up-to-date packages exists for B, C and D, but for one reason or an
> other you rebuild D after it was built as a dependency of C, when you
> build A: C will also be rebuilt; and since now C is newer that B, B will
> also be rebuilt.
> So rebuilding D after B and C were built is equivalent for tindy's way
> of building ports to bumping PORTREVISION for C and B.

Well, I'd call it a feature. I like this behavior when I worked with
new f8-linux ports generation. That gave me an opportunity to fix/change
some ports inline without numerous bumping PORTREVISION, rebuild the
fixed port and be sure that everything would be fine with other ports.
Even when I changed bsd.linux-rpm.mk it was enough to rebuild one
linux_base port to cause all dependencies to be rebuild automagically.

> Now think of a long dependency line (like, let's say one of the myriad
> of X ports, or perl, or ...); rebuild it and Tindy will end up
> rebuilding all ports depending on it.
>
>
> This leads to 2 big problems:
> 1. Ports being rebuilt when there's no reason --> lost time.
> 2. Problems being masked by this behaviour (ports being rebuilt
> silently that maybe needed PORTREVISION bump or something).
> (I do hope this is not the way pointy does it; if it is it would
> explain a lot of the strange differences between using ports and
> official packages).

My vote will be for introducing an option for tinderbuild that may
switch on the current behaviour. But switch off it by default.


WBR
-- 
Boris Samorodov (bsam)
Research Engineer, http://www.ipt.ru Telephone & Internet SP
FreeBSD committer, http://www.FreeBSD.org The Power To Serve