Details

    • Type: Task Task
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0-BETA4
    • Component/s: Tools
    • Security Level: All
    • Labels:
      None

      Description

      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.

        Activity

        Hide
        Benjamin Eberlei added a comment -

        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.

        Show
        Benjamin Eberlei added a comment - 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.
        Hide
        Jonathan H. Wage added a comment -

        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?

        Show
        Jonathan H. Wage added a comment - 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?
        Hide
        Benjamin Eberlei added a comment -

        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

        Show
        Benjamin Eberlei added a comment - 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
        Hide
        Roman S. Borschel added a comment -

        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.

        Show
        Roman S. Borschel added a comment - 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.
        Hide
        Jonathan H. Wage added a comment -

        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.

        Show
        Jonathan H. Wage added a comment - 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.
        Hide
        Benjamin Eberlei added a comment -

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

        Show
        Benjamin Eberlei added a comment - yes, but that is a downside of PEAR that we cannot influence.
        Hide
        Jonathan H. Wage added a comment -

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

        Show
        Jonathan H. Wage added a comment - So the same problem exists either way. Do we have anything to fix then?
        Hide
        Benjamin Eberlei added a comment -

        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.

        Show
        Benjamin Eberlei added a comment - 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.

          People

          • Assignee:
            Benjamin Eberlei
            Reporter:
            Benjamin Eberlei
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: