Catch 22 building gcc-wrapper

[Shprentz, J. [C] <Shp...@ni...>]

Summary: When building all packages from scratch, ark fails when it can't
satisfy a gcc-wrapper install-bits constraint to first deploy a certain
version of gcc.

Details:

The arrival of some new hardware inspired me to rebuild all packages on a
clean system.  All went well until ark tried to build gcc-wrapper.  The
install-bits method has a constraint requiring the default gcc to be
installed.  For example, this constraint appears in the Verilabs gcc-wrapper
package:

<contstraint><dependency type="normal" name="gcc" version-spec="eq 3.3"
on-method="deploy"/>

This worked when I last ran it, about six months ago.  Today, instead, ark
reported this message:

No thing matches constraint criteria: type=package name=gcc, version_spec=eq
3.3

I uncommented some print statements to debug the problem.  This tidbit was
printed by the pkgsWithName method of package.py:

name sought: gcc ['gcc-wrapper']

Apparently gcc-wrapper is on the candidate list when pkgsWithName is called
from _find_dependees in thing.py.  To my surprise, gcc-wrapper matched the
name sought, gcc.  Later, when the version_spec was checked, the match
failed.  Instead of finding gcc version 3.2.2, it found gcc-wrapper version
None.

What happened?  Among the changes last March to pkgsWithName, a test matches
name + "-wrapper".  We wanted gcc, but pkgsWithName also accepts names
starting gcc-- or gcc-wrapper.  This would be reasonable when building
packages other than gcc-wrapper.

Question:  What is the best way to force gcc--3.2.2 to deploy before
gcc-wrapper's install-bits method?

--

Joel Shprentz
National Imagery and Mapping Agency
Mailstop N-17
Washington Navy Yard, Building 213
1200 First Street, SE
Washington, DC 20303-0001

202-685-3534