ports rebuilt w/o good reason
bsam at ipt.ru
Sun Nov 30 08:39:24 EST 2008
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.
Boris Samorodov (bsam)
Research Engineer, http://www.ipt.ru Telephone & Internet SP
FreeBSD committer, http://www.FreeBSD.org The Power To Serve
More information about the tinderbox-list