mirror of
https://github.com/doctrine/orm.git
synced 2026-04-30 01:43:20 +02:00
DDC-684: Flaw in Build Process? #843
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @doctrinebot on GitHub (Jul 11, 2010).
Originally assigned to: @beberlei on GitHub.
Jira issue originally created by user @beberlei:
As I see it from our build script, each PEAR package of ORM and DBAL includes the Common sources again, although it sets itself as dependent on that package? That would mean the ORM package overwrites the files from the DBAL and Common packages.
@doctrinebot commented on GitHub (Aug 7, 2010):
Comment created by @beberlei:
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.
@doctrinebot commented on GitHub (Aug 7, 2010):
Comment created by @jwage:
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?
@doctrinebot commented on GitHub (Aug 7, 2010):
Comment created by @beberlei:
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 ;-)
@doctrinebot commented on GitHub (Aug 30, 2010):
Comment created by romanb:
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.
@doctrinebot commented on GitHub (Aug 30, 2010):
Comment created by @jwage:
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.
@doctrinebot commented on GitHub (Aug 30, 2010):
Comment created by @beberlei:
yes, but that is a downside of PEAR that we cannot influence.
@doctrinebot commented on GitHub (Aug 30, 2010):
Comment created by @jwage:
So the same problem exists either way. Do we have anything to fix then?
@doctrinebot commented on GitHub (Aug 30, 2010):
Comment created by @beberlei:
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 configuration for d51PearPkg2 task.
@doctrinebot commented on GitHub (Aug 30, 2010):
Issue was closed with resolution "Fixed"