Conceptionally a prerelease uses a single chroot environment.

Therefore all dependencies for all packages get installed at the same time.

This might hide missing dependencies in some of the packages.

I am pretty sure that was the different behavior you have been experiencing.

In order to achieve the same behavior as binarydeb jobs each package would need to be build in its own chroot environment which would require much more computational effort.

This would also require that all previous packages can be installed from Debian packages (to avoid installing all build dependencies).

While the goal to make both jobs behave identical is a good one (and we will aim for it in the future) there is currently no way to change the buildfarm in that way.

We will consider this important goal for the next iteration of the build infrastructure but that will not be something we can address in the near term.

Cheers,

- Dirk

On Sat, Apr 12, 2014 at 11:59 AM, G.A. vd. Hoorn - 3ME <g.a.vanderhoorn@tudelft.nl> wrote:

Mike Purvis wrote:
> Hey folks,
>
> I just had an issue where a pre-release succeeded, but the ultimate release
> failed to build. It's a repo containing multiple packages, and the fault
> came down to the fact that a prerelease checks out the whole repo and
> builds it as one workspace, whereas a release builds each package in total
> isolation.
>
> Is there any way to make the prerelease a closer match to the actual
> release, so that the prerelease check a better predictor of release success?

Not a real answer to your question, but what I've been doing is to
locally build each package using catkin_make_isolated, after having
verified the manifests & CMakeLists using catkin_lint. This seems to
catch most of my mistakes.

Gijs
_______________________________________________
ros-release mailing list
ros-release@code.ros.org
http://lists.ros.org/mailman/listinfo/ros-release