FTBFS: build time test error due to circular build dependency

Bug #2059173 reported by Athos Ribeiro
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
php-parser (Ubuntu)
New
Undecided
Unassigned
php-phar-io-manifest (Ubuntu)
New
Undecided
Unassigned

Bug Description

Due to a circular build dependency (phpunit dependency chain), php-parser is pulled during its own package build time.

Since php packages ship autoloaders that load the dependencies for a given package when a package is loaded, the installed version of php-parser is loaded when the system's phpunit is called.

This means that, when running the php-parser package test suite during build time, we are actually testing the installed version (or the previous version) of the package, and not the one being built.

This is mostly pointless and will trigger test errors when bug fixes include regression tests.

Below you will find a complete explanation of the issue as discussed in #debian-php in IRC.

For now, let's skip running the test suite for this package. Let's also keep this bug open since we should find an actual solution for the issue (and I also understand several other packages are affected by the same problem).

20:55 < athos> hey taffit ! I took some time to understand what was going on with
https://tracker.debian.org/news/1511003/accepted-php-parser-502-2-source-into-unstable/
20:56 < athos> I suppose I get it now (correct me if I am wrong)! There are 3 reverse
               dependencies pulling php-parser back (circular b-dependencies)
20:56 < athos> they are all phpunit dependencies
20:57 < athos> SebastianBergmann/{Complexity,LinesOfCode,CodeCoverage}
20:58 < athos> although we are getting the local php-parser in the path in d/rules (ln -s
               lib/PhpParser .)
20:59 < athos> the debian installed autoloaders will end up pulling the installed version of
               the package anyways
20:59 < athos> (the package being tested, in this case, php-parser)
21:02 < athos> This is the first occurence of the issue I have seen, but now I am wondering
               if this is the case for anything in the phpunit dependency tree
21:05 < athos> if it is, so, for those packges, we are actually testing the previous version
               of the package each time we upload them and sometimes tests will break (that
               is the point of unit tests!) and that is why we (you) do the binary package
               upload before pushing the sources
21:09 < athos> I wonder if it makes sense to run the tests during build time for these
               packages at all.
21:19 < athos> But more importantly, I wonder how we could improve the situation so we can
               ensure the package being built is loaded instead of the installed one in those
               situations

04:10 < taffit> athos: I haven’t yet succedded to ensure the new package is being tested at
                build time (and am not sure it’s possible, given the installed package is
                actually in use by PHPUnit dependency chain).
04:14 < taffit> Maybe by using “require_once __DIR__ . '/../<relative_path>/autoload.php”
                instead of “require_once '/usr/share/php/<absolute_path>/autoload.php“ in all
                autoload.php of the dependency chain AND making a symlink tree at package
                build.
04:14 < taffit> (as is currently done for composer and symfony, at least partly)

Revision history for this message
Athos Ribeiro (athos-ribeiro) wrote :

php-phar-io-manifest is also affected (this is a phpunit dependency)

description: updated
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.