Flaw in Build Process?

Assigned to jon.

One solution would be to change the package.xml to reference only the ORM code, although DBAL and Common are also shipped.

Hmm. I don't understand what you mean. The ORM includes the DBAL and Common code and installs it? Should it not do that and require that you install the dependencies via PEAR?

yes, otherwise if you install DBAL after ORM, the DBAL code will overwrite the DBAL code from the ORM. Or the other way around.

Plus if you deinstall DBAL it will deinstall the DBAL code although ORM might still be installed.

I can come up with about 20 other scenarios where this is problematic

Can we address this for BETA4 or should we push that to RC1 ? After releasing beta4 we still have time to address a lot of things before we go into RC.

I think the only solution is for the pear packages to only include the specific code for that package and the dependencies installed via pear. But even then, installing the ORM will require a certain version of the DBAL, so if you already have a version of the DBAL installed, it will need you to install the version the ORM requires. So either way you can't mix and match packages. If you use the ORM, you wouldn't ever have your own version of Common and DBAL installed because they would conflict.

yes, but that is a downside of PEAR that we cannot influence.

So the same problem exists either way. Do we have anything to fix then?

Fixed:

http://github.com/doctrine/dbal/commit/8054984a0448c54d5c658f60707b9ac490425c8b
http://github.com/doctrine/doctrine2/commit/803e33836518b7c019db667f482601f55803c29d

2 packages are now generated, one full package and one PEAR package. The PEAR package does not contain its dependencies, instead defines where to fetch them using the <dependencies><package> configuration for d51PearPkg2 task.