Bug#309185: tetex-bin: FTBFS in experimental: Endless loop.

[Florent Rougon <f.rougon@free.fr>]

Kurt Roeckx <kurt@roeckx.be> wrote:

> Note that I'm doing this on a 2.6 kernel, which has sub-second
> timestamps on files, which might be why you're not seeing it.

Good to know (I'm working with a 2.4 kernel). Now, I have a possible
explanation:

Suppose we start debian/rules with the rules file in 3.0-3.

10 Make sees this rule:

   % :: %.in $(eperl_sourcefiles) 
        eperl -P -o $@ $<

   The rule applies to the Makefile being executed (debian/rules),
   therefore Make will see if it needs to be updated. In the
   $(eperl_sourcefiles) prerequesite, it sees the two .PHONY
   prerequesites, *automatically* runs the corresponding targets because
   they are .PHONY (this is a hypothesis I am making to explain the
   whole thing), and then, only then, checks whether debian/rules is
   older than any of the prerequesite files, in particular
   debian/common.variables and debian/common.functions that have just
   been updated by the .PHONY target.

   On your system, this is always the case because of the subsecond
   timestamps. Therefore, debian/rules is regenerated and make reruns
   itself with the new one. GOTO 10. :-)

On my and Frank's systems, the loop quickly breaks because it is easy to
do the following in less than 1 second:
  - Make regenerates debian/rules
  - Make reruns itself with the new rules file
  - Make runs the .PHONY targets and updates common.variables and
    common.functions

Now, Make checks the time stamps of the new debian/rules and the
newer-but-still-generated-in-the-same-second common.variables and
common.functions, sees that they are all equal and concludes that rules
doesn't need to be regenerated. Thus, the build can start normally.

> The patch seems to work, and it seems to have build fine now.

Good, thanks.

-- 
Florent